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ABSTRACT 


The  purpose  of  this  thesis  is  to  design,  develop  and  implement  a  personnel  locator 
system  at  the  Naval  Postgraduate  School  (NPS).  A  prototype  locator  system  was 
developed  and  implemented  on  the  NPS  TCP/IP  network.  The  locator  provides 
information  such  as  email  addresses,  phone  and  fax  numbers,  and  building  and  office 
locations,  as  well  as  facilities  such  as  hotlinks  for  email  applications  and  homepages.  In 
addition,  the  NPS  Locator  automatically  updates  its  personnel  information  on  a 
configurable  time  schedule.  This  thesis  includes  a  discussion  of  the  prototype 
development  to  include  requirements,  tools,  and  design.  Some  program  code  is  included 
as  appendices.  This  paper  also  discusses  the  benefits  and  considerations  of  intranet 
technology,  and  explores  a  popular  Web  application  architecture  on  which  the  NPS 
Locator  is  based.  Finally,  this  thesis  makes  recommendations  for  improvements  to  the 
NPS  computing  environment  to  allow  for  future  intranet  development. 
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I.  INTRODUCTION 


The  purpose  of  this  thesis  is  to  design,  develop  and  implement  a  personnel  locator 
system  at  the  Naval  Postgraduate  School  (NPS).  The  locator  will  provide  information 
such  as  email  addresses,  phone  and  fax  numbers,  and  building  and  office  locations,  as 
well  as  facilities  such  as  hotlinks  for  email  applications  and  homepages.  The  impetus  for 
the  NPS  Locator  system  was  twofold.  The  first  spawned  from  the  “Strategic  Plan  for 
Computing  at  the  Naval  Postgraduate  School,”  published  late  1995.  In  an  effort  to 
improve  the  computing  infrastructure  at  NPS,  the  Associate  Provost  of  Computing  was 
interested  in  testing  the  viability  of  intranet  technology  as  an  application  deployment 
platform  for  campus-wide  systems.  A  locator  system  was  selected  as  one  of  the  first 
applications  because  of  its  relative  simplicity,  and  because  its  usefulness  should  attract 
users,  resulting  in  exposure  for  intranet  technology  at  NPS.  The  second  impetus  arose 
from,  simply,  the  lack  of  any  existing  accurate  and  complete  directory  system  at  the  time 
this  study  was  conceived. 

A.  THE  NPS  COMPUTING  ENVIRONMENT 

The  Strategic  Plan  mentioned  above  addresses  many  different  facets  of  the  NPS 
computing  environment.  Two  issues  that  are  relevant  to  this  thesis  are  the 
communications  network  and  administrative  application  development.  The  network,  as 
the  document  states,  “is  fragmented  and  unreliable,  held  together  by  bailing  wire  and 
sweat.”  The  Associate  Provost’s  goal  is  to  have  a  network  that  is,  “ubiquitous,  reliable, 
transparent,  and  (that  is)  easy  to  use  as  a  modem  telephone  system.”  The  network  is 
fragmented  because,  in  the  past,  the  enterprise  perspective  of  the  network  was  not 
acknowledged.  Networks  were  built  and  administered  independent  of  each  other,  usually 
along  departmental  lines.  This  independent  growth  resulted  in  a  network  that  consists  of 
at  least  four  different  network  operating  systems  (NOS),  various  resource  sharing  and 
access  capabilities,  minimal  interoperability,  various  email  naming  schemes,  and  different 
directory  systems  for  each  NOS. 

The  development  of  administrative  applications  also  fell  victim  to  this 
decentralized  and  haphazard  approach  to  information  technology  management. 
Applications  were  developed  and  data  sources  created  within  an  organizational  unit 
without  consideration  of  needs  outside  of  the  particular  organizational  unit.  This  lead  to 
duplication  of  effort  and  did  not  foster  interoperability.  These  “stovepipe”  applications 
have  different  data  requirements,  different  hardware  requirements,  and,  for  the  most  part. 
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are  not  widely  accessible  from  outside  the  organizational  unit  in  which  they  were 
developed. 

These  issues  provoked  a  grass-roots  exploration  into  intranet  technology  from 
several  faculty,  staff,  and  students  including  the  Associate  Provost  of  Computing. 
Several  independent  theses  have  been  written  to  address  various  aspects  of  intranet 
technology  and  how  it  can  be  applied  in  the  NPS  computing  environment.  Chapter  II 
discusses  the  benefits  and  considerations  of  intranets.  Again,  the  focus  of  this  work  is  to 
build  an  intranet  application,  the  NPS  Locator  directory  system,  using  industrial  strength 
tools  that  are  already  being  used  by  the  NPS  computing  staff  to  serve  as  a  demonstration 
of  intranet  viability  at  NPS. 

B.  SURVEY  OF  NPS  DIRECTORIES 

At  the  time  this  study  was  undertaken  the  directories  that  existed  at  NPS  were 
inaccurate  and  incomplete.  Accuracy  in  this  context  refers  not  only  to  phone  numbers, 
email  addresses,  and  descriptive  information  being  outdated  and  incorrect,  but  also  to 
misspellings  of  the  data.  Completeness  of  the  directory  refers  to  the  content  of  the 
directories.  For  example,  one  directory,  the  phone  book,  only  provides  phone  numbers, 
whereas  the  UNIX  “finger”  application  may  only  provide  email  information.  A  complete 
directory  should  provide  information  to  commvmicate  or  “locate”  a  person  by  all  available 
means. 

The  preexisting  directories  included  the  NPS  paper  phone  book,  UNIX  “ph”  and 
“finger”  programs,  proprietary  network  directories  (e.g..  Banyan  Vines  StreetTalk 
Directory)  and  a  variety  of  uncoordinated  and  unmanaged  Web  directories,  some 
containing  departmental  information  only.  These  directories  also  required  frequent 
manual  updates  if  they  were  to  stay  current. 

These  preexisting  directories  varied  greatly  in  many  aspects.  By  reviewing  the 
directories,  and  correlating  notes  on  their  strengths  and  weaknesses,  seven  characteristics 
of  directory  systems  became  apparent.  The  characteristics  later  drove  the  requirements 
and  design  of  the  NPS  Locator  Prototype.  The  characteristics  are  as  follows: 

1.  Scope 

The  scope  of  the  directory  refers  to  the  type  entities  listed.  For  example,  many  of 
the  directories  only  have  staff  and  faculty  in  them.  Others  only  have  staff  and  faculty 
from  within  a  particular  department.  The  desired  scope  includes  faculty,  staff  and 
students  from  the  entire  Naval  Postgraduate  School  population. 
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2.  Completeness 

The  completeness  of  the  directory  refers  to  the  attributes  listed  on  each  entity  in 
the  directory.  For  example,  some  directories  only  list  phone  number,  ofiBce  and 
department.  The  desired  list  of  entity  attributes  were  chosen  by  testing  each  of  them 
against  the  following  premise:  An  attribute  must  enhance  or  enable  either  the  process  of 
locating  an  individual  or  the  actual  communication  with  the  individual.  For  example,  if 
an  individual  needs  to  communicate  with  another,  the  office  number  may  enable  the 
process  by  letting  the  first  individual  physically  locate  the  second  individual.  A 
photograph  may  also  aid  in  the  process  if  the  individuals  have  never  met  in  person 
previously. 

3.  Accessibility 

Accessibility  is  concerned,  in  part,  with  who  has  authorization  to  use  the 
directory.  Many  of  the  directories  were  limited  to  NFS  personnel  use,  others  were 
available  to  the  Internet  community.  In  addition,  accessibility  deals  with  the  ease  of 
access  to  the  directory.  Some  directories  were  deeply  hidden  in  a  department’s  own  Web 
pages,  and  not  publicly  known  or  advertised  to  the  rest  of  NFS.  The  directory  should  be 
available  for  all  to  use,  with  perhaps,  various  views  depending  on  whether  access  is  from 
outside  or  from  within  the  NFS  intranet.  Furthermore,  the  directory  should  be  easy  to  get 
to  and  should  be  made  known  to  all  of  NFS.  The  most  obvious  location  for  an  NFS-wide 
directory  would  be  on  the  NFS  homepage. 

4.  Platform  Dependence 

The  directory  should  be  available  on  a  platform  that  is  readily  available  to  the 
largest  population  at  NFS.  This  requirement  imequivocally  points  to  the  Web  as  the 
platform  of  choice,  since  most  NFS  personnel  have  access  to  the  Internet  and  the  Web. 
Some  of  the  directories  reviewed  either  required  the  user  to  be  on  a  proprietary  LAN  or 
required  the  user  to  use  a  particular  operating  system.  For  example,  users  can  only  access 
the  StreetTalk  Directory  System  from  a  Banyan  Vines  network  client. 

5.  Updates 

All  of  the  directories  surveyed  required  manual  updating.  Few,  if  any,  had  any 
regular  update  schedule.  It  is  important  to  note,  however,  that  most  of  the  directories 
only  contained  staff  and  faculty  listings,  which  contain  rather  static  attributes.  The 


3 


student  population  changes  every  quarter,  and  therefore  provides  more  of  a  challenge  to 
the  directory  update  issue.  It  is  preferable  to  automate  the  update  process  for  two  reasons. 
Firstly,  updating  the  directory  would  most  probably  be  a  collateral  duty  for  the 
responsible  person,  and  certainly  would  not  receive  first  priority.  Maintaining  a  directory 
manually  can  be  a  tedious  undertaking,  especially  if  the  directory  is  robust  with 
information  from  a  variety  of  data  sources.  With  an  automated  update  process,  increasing 
the  frequency  of  updates  adds  no  burden  to  an  individual,  and  because  it  is  automated,  it 
can  be  run  at  off-peak  hours,  therefore  not  impacting  on  NFS  computer  resources  during 
peak  hours. 

6.  Data  Sources 

The  surveyed  directories  used  a  variety  of  data  sources.  Some  directories  received 
their  data  from  the  data  owners  initially,  but  then  did  not  refresh  that  data  on  a  regular 
basis,  if  at  all.  Others  used  second-hand  data  sources,  such  as  departmental  databases, 
which  probably  originated  from  the  data  owners.  Again,  no  update  method  was  in  place 
to  synchronize  the  data  with  the  data  owner’s  data  source.  Still  others  created  their  data 
locally. 

The  desired  data  sources  are  those  that  reside  with  the  data  owners.  The  data 
owners  should  have  the  most  accurate  and  update  information  on  the  entities  that  they  are 
responsible  for.  For  example,  the  Human  Resources  Office  (HRO)  should  have  the  most 
accurate  information  for  civilian  staff  and  faculty.  This  is  not  necessarily  true  for  all 
attributes.  For  example,  civilian  faculty  homepage  addresses  and  class  schedules  would 
not  be  under  the  HRO  ownership.  The  Registrar  would  own  the  class  schedules  and 
perhaps  the  computing  center  would  own  the  homepage  information.  The  data  ownership 
issue  assumes  that  the  owner  is  properly  maintaining  the  data. 

7.  User  Interface 

Finally,  the  user  interfaces  of  the  surveyed  directories  varied  greatly.  Some  were 
command-line  oriented,  such  as  the  “ph”  interface,  which  is  clumsy  and  not  very 
powerful.  Others  varied  between  DOS  menu  systems  and  Windows  point-and-click 
interfaces  with  varying  degrees  of  complexity  and  usefulness.  A  few  Web-based 
directories  had  good  interfaces  that  were  indeed  easy  to  use. 

A  directory  should  be  easy  to  use  and  understand.  The  Web  browser,  with  its 
point-and-click  nature,  provides  users  with  an  intuitive  way  to  navigate  through 
applications  and  locate  the  information  they  need  using  a  common  look  and  feel.  The 
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directory’s  interface  design  within  the  browser  still  requires  thought,  however,  to  ensure 
it  is  predictable  and  intuitive. 

C.  THESIS  ORGANIZATION 

This  thesis  has  two  main  logical  parts.  The  first  part  looks  at  intranets,  providing 
a  fairly  thorough  introduction  into  the  technology  and  into  the  benefits  and  considerations 
of  implementing  an  intranet.  In  addition,  a  generic  web  application  architecture  is 
discussed  to  provide  some  backgroxmd  into  the  architecture  of  the  NFS  Locator  System. 

The  second  logical  part  explains  the  development  of  the  NFS  Locator  from 
requirements  through  the  fimctional  capabilities  of  the  prototype  implementation.  The 
outline  of  this  thesis  is,  therefore,  as  follows; 

•  Chapter  I .  Introduction.  This  chapter  provides  an  overview  of  the  paper  and 
discusses  preexisting  directories  at  NFS. 

•  Chapter  11.  Introduction  to  Intranets.  This  chapter  introduces  intranet 
technology,  its  benefits  and  considerations,  and  ends  with  a  discussion  of  a 
common  web  application  architecture. 

•  Chapter  III.  NFS  Locator  Development.  Chapter  III  provides  the  central 
focus  of  this  thesis,  the  development  of  the  NFS  Locator  System.  This  chapter 
reviews  the  requirements,  tools,  architecture,  and  functional  aspects  of  the 
Locator. 

•  Chapter  IV.  Conclusion  and  Recommendations. 
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II.  INTRODUCTION  TO  INTRANETS 


The  NFS  Associate  Provost  of  Computing  is  not  alone  with  his  interest  in  intranet 
technology.  Numerous  corporations  and  government  installations  are  aggressively 
building  intranets  within  their  organizations.  This  interest  comes  on  the  heels  of  the 
recent  success  of  the  Internet  and  the  World  Wide  Web  (WWW).  Many  organizations 
want  to  exploit  diis  inexpensive  Web  technology  (Web  browsers  and  Web  servers).  This 
section  will  define  intranet,  as  well  as  discuss  the  technology  and  the  benefits  that  this 
technology  provides. 

A.  INTRANET  DEFINED 

An  intranet  is  an  internal  network  based  on  the  same  technologies  used  on  the 
Internet  and  the  World  Wide  Web.  The  Internet  is  the  global  internetwork  (i.e.,  network 
of  networks)  that  links  tens  of  thousands  of  organizations — ^government,  commercial  and 
educational — ^from  all  over  the  globe.  The  Internet  began  as  a  Department  of  Defense 
(DOD)  project  in  the  late  1960’s.  The  growing  importance  of  computers  at  that  time  gave 
rise  to  multiple  challenges  both  in  sharing  information  among  different  locations  with 
different  hardware  and  with  keeping  information  intact  during  potential  network 
disruptions  at  an  individual  site.  The  project  resulted  in  the  building  of  a  network  that 
intercoimected  various  educational  institutions  and  government  installations.  This 
network  was  called  ARPANET  (Advanced  Research  Projects  Agency  Network),  which 
evolved  into  what  now  is  known  as  the  Internet. 

The  Internet  utilizes  the  TCP/IP  (Transmission  Control  Protocol/Intemet 
Protocol)  suite  to  intercoimect  these  various  computers  and  networks.  IP  allows  these 
distributed  networks  to  route  and  pass  information  to  each  other  independently,  so  if  one 
site  is  down  the  information  can  be  routed  through  alternate  sites  to  its  final  destination. 
The  wide  use  of  IP  protocol,  and  hence  the  Internet,  has  made  IP  a  de  facto  standard. 
(Telleen,  1996) 

Web  technology  has  its  roots  in  research  carried  out  at  the  European  Particle 
Physics  Laboratory,  CERN,  in  the  early  1990’s.  This  project  focused  on  a  way  of  sharing 
information  using  hypertext  links.  Hypertext  links  are  special  codes  that  are  embedded  in 
a  document  that  provide  a  way  to  jump  to  another  part  of  tiie  same  document  or  to  a 
different  document.  Initially,  the  capability  was  limited  to  linking  documents  within  a 
single  computer.  The  functionality  was  extended  to  allow  one  to  select  documents  (or 
pages)  on  other  computers  at  different  sites  on  the  Internet.  The  hypertext  transfer 
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protocol  (HTTP)  was  the  protocol  developed  to  provide  this  “remote”  capability. 
HyperText  Markup  Language  (HTML)  is  the  file  standard  used  in  developing  the 
hypertext  documents  or  pages.  It  defines  the  “codes”  necessary  to  create  hypertext  links 
as  well  as  codes  to  enhance  the  presentation  of  a  page.  HTML  documents  can  be  very 
dynamic,  often  containing  audio,  video,  and  animation. 

Web  technology  has  two  main  components:  a  server  (HTTP  server)  and  a  client 
(or  web  browser).  The  HTTP  server  (more  often  referred  to  as  a  Web  server)  serves  or 
transfers  an  HTML  document  to  the  web  browser.  The  web  browser  interprets  the  HTML 
document  and  displays  it  to  the  screen.  The  process  is  as  follows: 

•  Your  browser  reads  a  document  written  in  HTML  and  displays  it  for  you, 
interpreting  all  the  markup  codes  in  the  document. 

•  When  you  click  on  a  hypertext  link  (hyperlink)  in  that  document,  your 
browser  uses  HTTP  to  send  a  network  request  to  a  Web  server  to  access  the 
new  document  or  service  specified  by  the  hyperlink 

•  Also  using  the  HTTP  protocol,  the  Web  server  responds  to  the  request  with 
the  document  or  other  data  your  requested. 

•  Your  browser  software  then  reads  and  interprets  that  information  and  presents 
it  to  you  in  the  correct  format.  (Evans,  1 996) 

In  summary,  an  intranet  is  a  TCP/IP  network  which  is  internal  to  your 
organization,  containing  HTTP  servers  that  provide  HTML  documents  and  other  services 
to  Web  browsers  (e.g.,  Netscape’s  Navigator  or  Microsoft’s  Internet  Explorer)  running  on 
various  hardware  platforms  throughout  the  network. 


B.  INTRANET  BENEFITS 

This  section  outlines  the  more  prevalent  benefits  that  result  fi-om  instituting  an 
intranet.  This  list  is  not  confined  to  NPS,  but  focuses  on  how  organizations  in  general 
can  benefit  from  this  technology.  Other  benefits  may  be  realized  because  of  the  particular 
nature  of  an  orgamzation’s  business,  information,  and  communication  requirements;  the 
size  of  the  organization;  and  the  geographical  locations  of  its  components.  These  various 
aspects  may  align  well  with  the  intranet  concepts  and  then  allow  for  greater  benefits. 
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1.  Low  Implementation  Costs 

Web  technology  is  based  on  mature  and  “truly  open  standards  such  as  TCP/IP, 
HTTP,  HTML,  CGI,  and  Java,  and  thus  does  not  lock  organizations  into  proprietary 
technology  with  limitations  and  significant  costs.”  (Linthicum,  DBMS  1997)  The 
hardware  and  software  components  necessary  to  get  an  intranet  up  and  running  are  cheap. 
Often,  most  of  these  components  are  already  in  place.  For  example,  most  organizations 
have  some  sort  of  proprietary  network  already  running,  and  adding  TCP/IP  to  these 
networks  is  usually  a  simple  task.  Moreover,  most  network  operating  systems  today  are 
shipped  with  their  own  TCP/IP  stack,  eliminating  some  of  the  cost  for  an  intranet.  In 
addition,  many  PCs  today  come  with  a  Web  browser  already  loaded.  Even  if  these 
components  had  to  be  purchased,  they  are  relatively  inexpensive. 

Furthermore,  “Web  applications  driven  from  a  single  browser  require  less 
training,  and  deployment  costs  are  reduced  due  to  the  single  interface,  protocol,  and 
middleware  architecture.  Large  organizations  report  costs  of  less  than  $40  per  user  to 
create  and  intranet  infrastructure,  compared  to  approximately  $2000  per  user  for 
traditional  two-tier  client-server  application  infrastructure.”  (Linthicum,  DBMS  1997) 

2.  Universal  Client 

Another  benefit  of  intranets  is  the  multi-platform  nature  of  Web  browsers. 
Browsers  exist  for  most  operating  systems  that  are  windows-based  or  that  provide  some 
sort  of  graphical  user  interface  (GUI).  These  include  UNIX  (X-Windows),  Microsoft 
Windows  (3.11,  95,  and  NT),  Macintosh,  and  OS/2.  The  availability  of  browsers  across 
these  diverse  platforms  is  significant.  The  operating  environments  of  the  author,  Web 
and  applications  servers,  and  the  client  viewer  are  independent  of  each  other.  Any 
document  adhering  to  HTML  and  the  related  standards  which  is  served  by  an  HTTP 
server  can  be  accessed  by  any  client  regardless  of  the  operating  environment  from  which 
they  originated.  (Telleen,  1996) 

The  ubiquity  of  die  browser,  therefore,  brings  two  obvious  benefits.  The  first  is 
that  the  user  only  needs  to  learn  one  interface,  allowing  the  user  the  opportunity  to 
become  proficient  with  the  one  interface.  Also,  this  allows  training  and  support  costs  to 
be  focused  in  one  direction,  and  should  result  in  a  lower  costs  overall. 

The  second  benefit  deals  with  classic  client-server  application  deployment  issues. 
One  of  the  most  costly  aspects  of  client-server  development  in  a  multiplatform 
environment  is  developing  and  maintaining  a  separate  client  interface  for  each  platform. 
This  benefit  of  Web  browsers  is  important  to  the  concept  of  “thin-client”  architecture.  In 
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intranet-based  applications,  the  application  logic  is  located  either  on  a  Web  server  or  an 
application  server.  Therefore,  changes  to  the  application  can  be  made  centrally,  vvithout 
the  need  to  update  and  re-deploy  the  client,  which  would  require  considerable  time  and 
cost  in  a  mulitplatform  environment. 

3.  Simple  and  Intuitive  Interface 

The  Web  browsers  use  of  point-and-click  hyperlinking  technology  allows  users  to 
navigate  and  locate  information  easily.  This  type  of  interface  is  very  intuitive  and  easy  to 
leam.  Furthermore,  since  the  users  are  using  one  interface  to  access  information  and 
applications,  they  can  quickly  become  proficient  with  the  Web  pages  and  Web 
applications. 

4.  Information  Access 

The  Web  information  publishing  paradigm  has  two  primary  advantages.  The  first 
advantage  deals  tvith  the  “push-vs.-pull”  information  distribution  debate.  In  the  “push” 
mode,  “all”  information  is  sent  to  the  user,  and  the  user  must  decide  whetiier  to  read  or 
discard  the  information.  In  the  “pull”  mode,  users  only  pull  what  they  need.  The  “pull” 
mode  allows  a  person  to  be  more  efficient  and  selective  in  what  they  process,  instead  of 
wasting  their  time  sifting  through  hoards  of  mostly  non-essential  information.  The  Web 
is  well-suited  for  this.  Information  providers  can  publish  the  information  and  place  it  on 
a  Web  server.  Users  that  want  to  access  the  information,  have  the  choice  to  “pull”  it 
down  if  they  decide  it  is  essential  to  their  needs,  or  choose  to  ignore  it  if  it  is  not  essential 
to  their  needs. 

The  second  advantage  rises  from  the  simplicity  in  updating  Web  content.  For 
example,  in  the  past,  orgamzations  published  employee  handbooks  once  a  year  and 
distributed  them  to  all  employees.  Traditionally,  even  though  these  handbooks  may  have 
been  out  of  date  the  day  they  were  distributed,  they  would  not  be  updated  until  the 
following  year.  With  an  intranet  publishing  strategy,  information  can  be  updated 
instantly,  and  there  is  no  need  for  reprinting,  duplicating,  and  distributing  reams  of  ink 
and  paper.  Duplication  and  distribution  are  achieved  by  sunply  placing  the  handbook  on 
a  Web  server.  In  support  of  this  intranet  benefit,  “a  recent  International  Data  Corp.  (IDC) 
study  pegged  ROI  (return  on  investment)  at  1,000  percent  or  better— mostly  in  paper  and 
labor  costs.”  (Currid,  1997) 
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5.  Multimedia  Content 


Besides  the  quick  and  easy  access  to  timely  infonnation,  the  information  itself  can 
be  in  a  variety  of  formats,  including  text,  graphics,  video,  audio,  and  animation.  This  can 
enhance  the  exchange  of  information  and  allow  for  different  types  of  information  to  be 
conveyed.  Web  browsers  already  provide  capabilities  for  these  various  formats,  and 
therefore  intranets  provide  this  benefit  at  no  extra  cost. 

C.  INTRANET  CONSIDERATIONS 

Intranets  are  not  the  panacea  for  all  computing  and  information  needs  of  an 
organization.  The  benefits  discussed  above  do  not  come  fiee  without  certain 
considerations.  Three  main  considerations  are  explored  below: 

1.  Ease  of  Use 

Though  “ease  of  use”  is  a  benefit  of  Web  publishing  on  intranets,  it  also  can 
become  a  negative  attribute.  For  example,  it  is  easy  for  any  person  in  an  organization  to 
start  putting  content  out  on  the  internal  Web.  If  not  managed  in  some  way,  issues  of 
information  glut,  security,  privacy,  and  performance  may  become  significant,  resulting  in 
more  problems  and  a  negative  ROI.  Therefore,  much  consideration  into  how  the 
information  infirastructure  is  to  be  managed  must  be  put  forth  before  the  intranet  takes  off. 
How  to  manage  the  content  producing  infrastructure  in  an  intranet  is  a  topic  of  great 
debate  and  is  beyond  the  scope  of  this  thesis.  In  short,  the  debate  centers  aroimd 
centralized  or  decentralized  control  of  content  production.  If  control  is  decentralized, 
how  does  one  ensiue  the  content  developed  adds  value  to  the  organization,  or  at  a 
minimum,  does  not  detract  firom  the  mission?  On  the  other  hand,  if  control  is  centralized, 
is  the  effectiveness  and  creativity  of  the  organization  greatly  limited?  Most  successful 
intranets  seem  to  find  a  balance  between  the  two  approaches  to  content  management. 

2.  Security 

The  “ease  of  use”  issue  also  highlights  the  need  for  security.  If  information  is 
easily  accessible,  then  extra  care  must  be  taken  that  only  authorized  users  are  allowed 
access  to  certain  pieces  of  information.  Most  organizations  have  Internet  access,  and 
therefore  a  potential  hole  into  the  intranet  exists  via  this  Internet  connection.  Firewalls 
are  special  workstations  that  control  access  between  your  intranet  and  die  Internet.  Great 
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care  must  be  taken  in  the  administration  of  firewalls  and  other  security  measures  because 
of  the  speed  with  which  information  can  flow  through  an  intranet  and  out  to  the  Internet. 
For  example,  if  an  administrator  incorrectly  sets  permissions  on  a  document  outlying 
future  strategies  of  a  corporation  that  only  the  executive  staff  is  supposed  to  see,  and  the 
whole  Internet  has  access  to  it,  competitors  may  view  it  and  restructure  their  business 
accordingly. 

3.  Interactive  Application  Development 

The  traditional  Web  technology  was  never  designed  to  support  interactive 
applications.  HTTP  and  HTML  form  a  “request-download-view-disconnect”  type  of 
architecture  and  cannot  process  applications  interactively.  (Linthicum,  DBMS  1997) 

Interactive  applications  require  persistent  connections  between  client  and  server. 
HTTP  makes  a  connection,  downloads  a  document,  and  then  closes  the  connection.  It  has 
no  mechanism  to  maintain  a  persistent  connection.  Furthermore,  the  original  Web 
architecture  could  only  deliver  static  content.  Web  pages  had  to  be  prepared  beforehand, 
and  placed  on  the  web  server  for  delivery.  No  mechanism  existed  to  deliver  dynamic 
content.  In  other  words,  there  was  no  way  to  create  pages  on-the-fly.  This  capability  is 
necessary  for  interactive  application  development. 

D.  WEB  APPLICATION  ARCHITECTURE 

Originally,  as  stated  above,  the  Web  could  only  publish  or  present  static  content. 
With  the  introduction  of  CGI  (common  gateway  interface),  a  Web  server  could  tiien 
deliver  dynamic  content  back  to  the  user’s  Web  browser.  CGI  is  a  protocol  that  defines 
how  an  external  process  on  a  Web  server  can  create  dynamic  Web  pages.  CGI  programs 
work  in  the  following  manner:  The  Web  server  runs  the  CGI  program  on  behalf  of  a 
user,  the  CGI  program  does  some  processing,  creates  an  output  HTML  document,  and 
then  stores  it  in  an  agreed  upon  filename  or  memory  location.  When  the  CGI  program 
exits,  the  Web  server  delivers  the  document  back  to  the  client  Web  browser.  The  CGI 
program  may  do  calculations  based  on  input  from  the  user,  or  it  may  access  a  database 
and  create  a  document  with  the  requested  information.  The  CGI  program  can  be  written 
in  any  language  supported  by  the  Web  server’s  operating  system.  For  example,  the  NPS 
Locator  Web  server  (WebSite  1.1)  runs  on  Windows  NT;  therefore,  any  programming 
language  supported  by  Windows  NT  czin  be  used  for  CGI  programs  Some  common 
languages  may  include  Visual  Basic,  C-H-,  Powerbuilder,  Java,  and  Delphi. 
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One  drawback  of  a  traditional  CGI  executables  is  their  inefficiency  when 
connecting  to  a  database.  Each  time  a  user  requests  a  dynamic  page  of  data,  the  Web 
server  creates  a  new  CGI  process,  connects  to  the  data  source,  receives  the  data,  closes 
the  connection  and  shuts  down  the  CGI  process.  The  larger  the  CGI  program,  the  more 
overhead  is  created  on  the  Web  server,  resulting  in  slower  performance.  In  addition, 
much  overhead  is  incurred  from  opening  and  closing  a  database  connection. 

To  address  some  of  the  inefficiencies  of  CGI,  most  Web  server  vendors  provide 
an  application  programming  interface  (API),  which  allows  direct  access  to  server-side 
applications  that  run  as  part  of  the  Web  server.  “In  most  cases  this  leads  to  faster  and 
more  compact  memory-wise  equivalents  to  CGI  programs,  though  no  longer  portable.” 
(Kohlhepp,  1997)  “Functions  written  to  a  server’s  APIs  can  be  multithreaded,  therefore, 
one  process  can  service  multiple  requests,  keeping  the  memory  requirement  down.” 
(Kohlhepp,  1997)  CGI,  on  the  other  hand,  must  start  a  new  process  for  each  request. 

Though  APIs  can  have  better  performance  than  CGI,  APIs  can  crash  a  web  server 
because  of  the  shared  web  server  memory  space.  CGI  extensions  are  separate  programs 
that  cannot  affect  the  operation  of  the  web  server  itself  Web  applications  that  use  the 
API  extensions  approach  are  much  more  complex  and  demand  advanced  programming 
skills  such  as  “multithreading  and  concurrency  synchronization,  network  protocol 
programming  and  structured  exception  handling.”  (Denny,  1996) 

It  is  important  to  note  that  both  approaches  provide  the  same  functionality  within 
the  application  architecture,  the  only  difference  being  the  issue  of  performance.  Both 
approaches  still  require  opening  and  closing  of  data  connections. 

Furthermore,  both  methods  fail  in  the  area  of  state  management.  HTTP  is  a 
stateless  protocol.  Each  browser  request  is  distinct,  and  in  its  raw  form,  completely 
disassociated  from  any  prior  request.  This  works  well  for  static  HTML  pages,  but  does 
not  work  in  a  database  application  for  transaction  management  or  navigation.  The  server 
needs  to  know  who  performed  what  operation  in  order  to  commit  a  transaction,  or  needs 
to  know  what  record  the  user  is  on  to  know  which  record  is  the  next  one.  By  the  nature 
of  the  Web,  there  is  never  a  constant  connection  to  the  Web  server,  so  this  information  is 
not  retained.  (Krull,  1997) 
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Many  vendors  have  developed  an  architecture  to  solve  the  issues  of  CGI 
performance,  persistent  data  connections  and  state  management.  This  architecture,  as 
seen  in  Figure  1,  has  four  main  components:  a  courier  module,  a  broker,  an  application 
agent,  and  a  database.  This  architecture  is  based  on  the  architectures  from  Borland, 
NetDynamics,  and  HREF  Systems.  The  architecture  has  been  generalized  and  some  of 
the  component  names  changed  to  simplify  the  discussion. 

Application  requests  flow  through  the  architecture  in  the  following  manner: 

1 .  The  Web  server  passes  a  browser’s  HTTP  request  to  the  broker  module 


through  a  courier,  which  is  either  a  lightweight  CGI  “stub”  (1 5-50kb  for  most 
implementations),  or  a  Web  Server  API-based  (NS  API  or  IS  API)  dynamic 
link  library  (DLL). 

2.  The  broker  receives  the  request  from  the  courier  and  then  passes  it  to  the 
appropriate  application  agent.  The  broker  is  responsible  for  assigning  a 
unique  session  ID  to  new  clients  so  that  user  “state”  can  be  maintained  across 
multiple  requests  from  the  same  user.  This  ID  is  included  in  every  HTML 
page  generated,  so  that  when  the  user  makes  a  subsequent  request,  fliey  will 
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pass  back  the  session  ID  with  their  request,  allowing  the  Application  Agent  to 
track  the  user. 

3.  The  Application  Agent  then  processes  the  request  by  accessing  a  database  and 
applying  any  necessary  business  logic.  The  Application  Agent  then  creates 
the  ouqjut  HTML  document  and  passes  it  back  to  the  Web  server  and  the 
Courier  module  shuts  down,  signaling  the  Web  server  to  deliver  the  document. 

In  this  architecture,  the  Application  Agents  stay  loaded  and  can  maintain  data 
connections,  eliminating  the  performance  problem  with  traditional  CGI  architecture.  In 
addition,  the  reduced  size  of  the  CGI  program  also  saves  in  resources  and  performance. 
In  this  architecture,  the  CGI  is  used  merely  to  pass  information  to  the  backend  system  and 
to  signal  when  the  HTML  document  is  ready  for  transmission  back  to  the  user. 

Most  vendors  allow  there  to  be  more  than  one  instance  of  an  Application  Agent  to 
be  running  at  a  time.  The  Broker  is  responsible  for  load-balancing  requests  across  the 
Agents.  In  addition,  most  systems  allow  the  Agents  to  be  located  on  different 
workstations,  therefore  allowing  for  scalability  of  the  system  by  adding  additional  remote 
servers  as  seen  in  the  architecture  diagram. 
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III.  NPS  LOCATOR  DEVELOPMENT 


A.  REQUIREMENTS 

In  developing  the  NPS  Locator  Prototype,  one  guiding  principle  existed:  The 
prototype  should  require  minimal  changes  to  the  NPS  computing  environment.  The 
computing  environment  refers  to  the  data  sources,  network  infrastructure,  and  client 
machines.  The  reason  for  this  requirement  was  to  eliminate  any  barriers,  political  or 
technical,  to  implementing  the  system.  Then,  after  the  prototype  has  been  implemented 
and  has  proved  its  value,  requests  for  changes  to  the  environment  may  be  made. 

The  remaining  portion  of  this  section  presents  the  requirements  defined  for  the 
design  and  fimctionality  of  the  NPS  Locator  prototype.  These  requirements  are  limited  in 
scope  because  of  the  prototype  nature  of  the  Locator  and  do  not  represent  the  “ideal” 
directory  system. 

1.  Functional  Requirements 

•  The  system  must  provide  a  means  for  NPS  personnel  to  obtain  communication 
and  location  information  on  any  other  person  at  NPS.  This  information 
includes  email  address,  phone  and  fax  numbers,  building  and  office  locations, 
homepage  URLs,  mail  codes,  position  title,  and  a  picture.  Any  information 
that  aids,  either  directly  or  indirectly,  the  location  of  or  eventual 
communication  with  a  particular  individual  should  be  included. 

•  The  system  must  provide  search  capabilities  to  locate  personnel  by  last  name, 
department,  and  status  (i.e.,  student,  staff,  or  faculty).  The  last  name  search 
should  provide  partial  name  searches  in  which  the  user  is  only  required  to 
input  the  first  few  letters  of  the  last  name. 

•  The  system  should  allow  users  to  augment  their  locator  listing  with 
information  they  provide  through  the  system.  Users  should  be  provided  with 
the  option  of  providing  other  information  that  enables  commxinication  with 
that  user.  For  example,  users  may  want  to  input  their  home  phone  and  mailing 
address,  or  they  may  want  to  provide  a  time  schedule  of  when  they  are 
available  for  phone  calls  and  appointments. 

•  The  system  should  maximize  the  use  of  built-in  communication  facilities.  For 
example,  if  using  web  browser  technology,  email  addresses  should  be 
presented  as  a  hypertext  link  that  when  selected  will  call  up  the  browser’s 
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built-in  mail  tool.  Also,  hyperlinks  should  be  used  when  possible  to  link  to 
additional  information  or  resources. 

•  The  locator  should  maximize  automatic  methods  of  updating  the  locator  data 
stores,  and  minimize  human  intervention.  Manual  updates  often  do  not  get 
done  on  a  regular  basis  because  they  can  be  very  tedious.  Automatic  updates 
are  easily  run  on  a  much  more  frequent  basis,  which  results  in  more  current 
data. 

2.  System  Requirements 

•  The  NFS  Locator  should  be  accessible  from  multiple  platforms  to  include 
UNIX  workstations,  PCs,  and  Macintosh  computers. 

•  The  system  should  require  little  or  no  additional  software  on  the  client 
machines  except  for  a  web  browser. 

•  The  system  should  be  accessible  from  any  network  that  supports  TCP/IP  and 
HTTP.  NPS  currently  has  four  major  network  operating  systems  (NOS) 
installed:  UNIX  TCP/IP,  Banyan  Vines,  Novell  NetWare,  and  AppleTalk. 
Currently,  all  these  NOS  support  TCP/IP. 

•  The  NPS  Locator  should  be  developed  with  standard  tools  that  are  familiar  to 
the  NPS  computing  support  staff.  These  tools  include  primarily  Borland 
Delphi  and  Oracle  development  products. 

3.  Data  Requirements 

The  data  sources  for  the  NPS  Locator  should  be  from  the  data  owners  to  ensure 
that  the  most  accurate  and  current  information  is  used.  The  Locator  should  either  directly 
access  the  original  data  for  its  queries,  or  it  should  build  its  own  data  store  from  the 
original  data.  If  building  its  own  data  store,  then  the  frequency  of  the  updates  must  be  set 
such  that  the  updates  capture  most  of  the  changes  to  the  original  source. 

B.  DEVELOPMENT  TOOLS 

The  tools  selected  for  the  prototype  development  were,  for  the  most  part,  dictated 
by  their  familiarity  within  the  NPS  computing  support  staff.  The  tools,  therefore,  may 
not  represent  the  best  tools  for  the  job,  but  did  allow  for  a  short  development  time, 
which  is  in  line  with  the  prototype  concept. 
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1.  Programming  Tools 

The  most  significant  tool  to  the  prototype  development  was  WebHub  fi'om  HREF 
Systems.  “WebHub  is  a  CGI  framework  for  building  dynamic,  database-driven  web  sites 
with  Delphi  for  deployment  on  Windows-based  web  servers.”  (HREF,  1996)  “A 
Framework  is  a  set  of  prefabricated  software  building  blocks  that  programmers  can  use, 
extend,  or  customize  for  specific  computing  solutions.”  (Taligent,  1997)  Frameworks 
prevent  a  software  developer  from  having  to  start  fi’om  scratch  each  time  he  writes  an 
application.  WebHub’s  framework  includes  “over  30  web-specific  Delphi  components” 
for  building  custom  made  web  applications.  WebHub  uses  the  Web  “broker-agent” 
architecture  discussed  above. 

Accordingly,  Delphi  was  used  in  conjunction  with  WebHub  to  add  the  business 
logic  specific  to  the  NPS  Locator  application.  Delphi  also  was  used  to  build  programs 
that  populate  the  Locator’s  database.  These  Delphi  programs  collect  data  firom  various 
data  sources  throughout  the  NPS  infrastructure,  normalize  it,  and  then  store  the  data  in  the 
database. 

Perl  allowed  data  aggregation  from  UNIX  platforms.  Perl  stands  for  Practical 
Extraction  and  Report  Language.  It  is  ideal  for  extracting  data  from  UNIX  file  systems 
and  then  formatting  that  data  into  specific  output  files. 

2.  Web  Server 

O’Reilly’s  WebSite  Web  Server  was  chosen  to  host  the  NPS  Locator  prototype 
because  of  its  wide  use  at  the  school.  WebSite  can  run  on  Intel  platforms  using  either 
Windows  95  or  Windows  NT.  The  WebSite-Windows  NT  combination  served  as  the 
NPS  Locator  Web  platform. 

3.  Database  Server 

Finally,  the  NPS  Locator  database  was  tested  on  two  platforms.  The  first  was  on 
an  Oracle  7.2  database  server.  The  database  server  platform  was  a  DEC  Alpha 
workstation  running  an  Alpha  version  of  Windows  NT.  Once  again,  the  selection  of  this 
component  resulted  from  its  availability  and  familiarity  at  NPS.  Some  expertise  existed 
with  the  Oracle  server  because  it  was  used  as  a  test  bed  for  possible  migration  from  the 
mainframe  database  to  a  client-server  workstation  environment.  The  second  test  was  run 
with  a  local  Paradox  database  resident  on  the  Web  server  machine.  Both  test  were 
successful  and  provided  acceptable  results. 
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C.  NPS  LOCATOR  ARCHITECTURE 

The  NPS  Locator  has  two  main  components:  the  NPS  Locator  Web  Application 
and  the  Locator  Update  component.  The  Web  Application  provides  the  user  interface, 
business  logic,  and  data  representation.  The  Update  component  gathers  data  from  a 
variety  of  data  sources,  parses  that  data,  normalizes  it,  and  then  stores  it  in  the  Locator 
database.  This  section  will  first  discuss  the  Update  component  and  then  follow  with  an 
explanation  of  die  Web  Application. 

1.  Update  Component 

The  Update  component  is  a  collection  of  data  sources,  automated  data-extraction 
scripts,  and  file^transfer  routines.  These  various  components  can  be  seen  in  Figure  2 
below. 


The  Update  component  can  be  broken  down  into  three  phases.  Phase  I  consists  of 
the  extraction  of  student  data  from  die  Curricular  Database,  extraction  of  email  and 
homepage  URL  information  from  the  Computer  Center  (CC)  UNIX  accounts,  and 
extraction  of  staff  and  faculty  information  from  the  Staff/Faculty  Database.  Phase  II 
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consists  of  “harvesting”  the  extracts  created  in  Phase  I,  and  storing  them  on  the  Web 
Server.  Phase  III  merges  the  extracts  and  then  stores  them  in  the  Locator’s  Oracle 
Database  Server.  Before  discussing  the  three  phases,  an  explanation  is  provided  of  how 
the  data  sources  were  selected  for  the  prototype  and  what  information  they  provide. 

a.  Data  Sources 

One  of  the  goals  of  the  prototype  is  to  eliminate,  or  at  least  minimize,  the 
duplication  of  effort  in  creating  and  maintaining  data  sources.  This  is  accomplished  by 
using  the  data  sources  of  the  data  owners.  A  “data  owner”  is,  for  the  purposes  of  this 
thesis,  a  person  or  organizational  body  that  is  responsible  for  the  creation  and 
maintenance  of  particular  data,  usually  relevant  to  their  organizational  function.  For 
example,  the  Registrar  is  the  “data  owner”  of  all  information  pertaining  to  grades  and 
class  schedules.  The  Registrar  creates  and  maintains  a  “Registrar  Database”  that  contains 
data  that  pertains  to  grades  and  class  schedules.  Therefore,  one  would  expect  that  the  best 
source  (i.e.,  the  most  accvnate  and  up-to-date)  for  such  information  would  be  the 
Registrar  Database. 

Using  data  ownership  as  the  primary  criterion  in  selecting  data  sources,  the 
Curricular  Officer’s  Database  was  selected  as  the  data  source  for  students’  personal 
information  and  the  CC  UNIX  user  accounts  were  selected  as  the  data  source  for  email 
and  homepage  URL  information.  The  information  extracted  from  the  Curricular 
Database  is  as  follows;  SSN,  name,  grade,  service,  student  mailbox  number,  department, 
curriculum,  section,  entry  date,  and  graduation  date. 

The  CC  UNIX  password  file  and  file  system  serve  as  the  second  data 
source  used  by  the  Update  component.  A  sample  line  entry  in  a  UNIX  password  file  is 
shown  below: 

jeforte:67kBjs/mctYuc:24865:20:Jeffrey  E.  Forte,  2513:/h/joshua_u2/jeforte:/bin/csh 

Each  field  in  the  password  file  is  separated  by  a  colon  The  fields 

are: 

•  username,  which  also  serves  as  the  email  address  (“jeforte”) 

•  password,  which  is  the  user’s  encrypted  password 

•  userid,  which  is  frie  unique  (to  the  UNIX  system)  numerical  ID  that  represents 
this  user 

•  groupid,  which  is  the  ID  of  the  group  to  which  this  user  belongs 
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•  quota  and  comment,  which  represent  different  things  on  different  machines 

•  infofield,  which  is  a  character  string  containing  personal  information  about  the 
user.  In  the  case  of  CC  accoxmts,  it  contains  the  user’s  full  name,  followed  by 
a  comma,  and  a  unique  four  digit  number  used  by  the  administrator  to  track 
the  user. 

•  homedir,  which  is  the  user’s  home  directory 

•  shell,  which  is  the  command  shell  that  is  started  when  the  user  logs  in 

The  information  extracted  from  the  password  file  includes  last  name,  first 
name,  middle  initial,  email  address,  and  home  directory.  The  home  directory  is  extracted 
in  order  to  determine  if  a  user  has  a  homepage.  If  a  user  of  the  CC  UNIX  system  wants 
to  have  a  homepage,  the  user  is  required  to  create  a  directory  called  “public  html”  under 
his  or  her  home  directory,  and  place  the  page  in  this  directory.  The  file  must  be  named 
“Welcome.html”  or  “Index.html.”  By  searching  the  home  directory,  it  can  be  determined 
if  the  user  has  a  homepage  by  searching  the  user’s  home  directory. 

The  final  data  source  used  is  a  staff  and  faculty  database  that  was  created 
for  use  by  the  prototype.  It  was  difficult  to  find  good  data  sources  for  staff  and  faculty 
information,  and  the  ones  that  did  exist,  were  not  readily  available  because  of 
bureaucratic  reasons.  Again,  since  the  staff  and  faculty  data  is  relatively  static  compared 
to  the  student  data,  for  the  purpose  of  the  prototype  this  database  was  sufficient.  The 
proof  in  concept  can  be  demonstrated  on  the  more  dynamic  student  data. 

b.  Phase  I 

In  Phase  I,  automated  scripts  extract  information  from  the  data  sources 
discussed  above,  and  then  store  the  data  as  ASCII  flat-files  on  the  respective  systems  in 
accounts  set  aside  for  the  Locator  system.  Refer  to  Figure  2.  Starting  from  the  left,  the 
first  data  extraction  routine  encountered  is  the  “FOCUS  Extract”  program.  This  program 
was  written  for  the  prototype  by  Judy  Harr,  a  FOCUS  database  administrator.  It  extracts 
student  information  from  the  Curricular  Officer’s  Database,  formats  it  into  an  ASCII  flat- 
file,  and  stores  it  in  a  special  mainframe  account  set  aside  for  the  Locator  prototype.  The 
frequency  of  this  process  is  adjustable,  and  was  set  to  process  once  a  day,  early  in  the 
morning  when  processing  levels  are  low. 

The  second  data  extraction  routine  consists  of  a  Perl  program  residing  on 
CC  UNIX  system.  This  program  parses  the  password  file,  and  pulls  out  each  username 
(email  address),  the  user’s  full  name,  and  his  or  her  home  directory.  When  it  gets  the 
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home  directory,  it  checks  to  see  if  a  “public_htmr’  directory  exists.  If  so,  it  then  looks  for 
a  filename  of  either  “Welcome-html”  or  “Index.html.”  At  this  point  it  writes  out  to  an 
ASCII  flat-file  with  the  following  format:  last  name,  first  name,  middle  initial,  last  name 
with  initials  appended,  homepage  URL  (if  one  exists),  and  username.  The  text  below 
shows  two  entries  in  the  resulting  file: 

FORTE  JEFFREY  E.  FORTEJE  http://vislab-www-nps-navy.mi l/^jeforte  jeforte 
EMERY  JAMES  C.  EMERY JC  jcemery 

The  Perl  program  is  executed  once  a  day  early  in  the  morning.  This  is 
accomplished  with  the  UNIX  “cron”  command,  which  executes  commands  at  specified 
dates  and  times. 

The  third  routine  would  be  the  extraction  of  staff  and  faculty  information 
from  the  staff  and  faculty  database.  Since  this  database  was  created  for  the  prototype 
specifically,  it  is  conveniently  located  on  the  Web  server  ready  for  the  Phase  III  process, 
and  therefore  no  real  extraction  is  taking  place.  If  this  database  did  not  exist,  the  third 
data  extraction  routine  would  probably  pull  information  from  the  Human  Resources 
database  as  well  as  other  pertinent  sources  of  staff  and  faculty  information.  This 
simulated  third  routine  concludes  Phase  I. 

c.  Phase  II 

Phase  II  can  be  considered  the  “harvesting”  phase.  In  this  phase,  all  of  the 
extraction  files  are  retrieved  from  their  originating  locations  and  stored  on  the  Locator 
Platform  (Windows  NT  server)  in  preparation  for  Phase  III.  Appropriately,  Phase  II  is 
accomplished  by  a  program  written  in  Delphi  named  “Harvest.exe.”  This  program  uses 
an  FTP  component  from  Netmanage  Corporation.  FTP  is  a  file  transfer  protocol  that 
works  on  top  of  TCP/IP.  It  is  useful  in  transferring  files  across  a  TCP/IP  network,  such 
as  the  NPS  Intranet.  The  Harvest  program,  which  is  resident  on  the  Locator  Windows 
NT  Server,  initiates  file  transfers  with  the  Locator  account  on  the  CC  UNIX  system  to 
retrieve  the  email/homepage  ASCII  flat-file,  and  with  the  Locator  account  on  the 
mainframe  to  retrieve  the  Curricular  Database  extract.  The  Harvest  program  is  setup  as  a 
Windows  NT  service,  which  allows  it  to  be  scheduled  to  execute  at  predetermined  times. 
In  this  case,  it  is  scheduled  to  run  everyday,  approximately  two  hours  after  the  extraction 
scripts  execute.  Once  the  files  are  residing  on  the  Locator  platform.  Phase  II  has 
successfully  completed.  At  this  point,  the  completion  of  the  Harvest  program  triggers 
Phase  III. 
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d.  Phase  III 


Phase  III  of  the  Update  component  takes  the  ASCII  flat-files  and  the 
StafE'Faculty  database  and  merges  them  together,  and  then  stores  the  resulting  data  in  the 
Locator  Oracle  database.  The  “Merge.exe”  program,  which  is  triggered  by  the 
completion  of  the  Harvest  program,  is  the  workhorse  of  the  third  phase.  The  Merge 
program  also  was  created  using  Delphi.  The  Delphi  TBatchMove  component  is  used  to 
convert  the  ASCII  files  into  the  standard  DBF  format  that  Delphi  supports.  This 
component  also  ensures  no  duplicate  index  keys  get  added  to  the  resulting  database.  The 
Merge  program  uses  this  function  with  the  last-name,  first-name,  middle-initial 
combination  to  eliminate  duplicate  records  for  all  personnel.  Then  each  of  the  converted 
databases  is  cleaned  and  standardized.  For  example,  the  Curricular  database  file  was 
inconsistent  on  how  it  handled  two-part  last  names  such  as  Van  Horn  and  Van 
Steenberger.  In  one  case,  the  two  parts  are  appended,  as  in  Vansteenberger.  In  the  other 
case,  the  two  are  separated  by  a  space,  as  in  Van  Horn.  This  inconsistency  makes  it 
difficult  to  merge  the  UNIX  extract  file  with  the  Curricular  extract  file  because  in  the 
UNIX  file  Vansteenberger  is  Van  Steenberger.  It  is  unfortunate  that  names  had  to  be 
used  as  the  index  key  for  the  merge,  but  the  UNIX  accounts  do  not  record  any  part  of  the 
SSN  or  other  usable  unique  identifier.  Moreover,  the  Curricular  database  does  not  store 
separately  the  last  name,  first  name,  and  middle  initial  of  a  student.  They  all  are 
combined  in  a  single  field  labeled  “name.”  As  a  result,  the  Merge  program  does  a  “best 
effort”  in  correlating  data  from  the  various  data  sources  using  the  components  of  a 
person’s  name.  For  the  most  part,  it  is  successful. 

After  cleaning  the  data,  the  Merge  program  uses  an  SQL  “Insert”  query  to 
update  the  Locator  s  Oracle  database  resident  on  a  DEC  Alpha.  In  essence,  the  Locator’s 
main  table  is  recreated  every  morning.  Following  the  rebuild  of  the  main  table,  another 
query  is  executed  that  links  records  in  the  main  table  with  the  “register”  table  which 
stores  information  on  users  who  have  registered  with  the  Locator  Application.  In  short, 
the  register  table  stores  the  login,  password,  and  other  information  with  which  the  user 
chose  to  augment  his  listing.  At  this  point,  the  Merge  program  exits,  and  the  Update 
component  hais  completed  its  function. 
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2.  NPS  Locator  Application 

The  Locator  Web  application  architecture  can  be  seen  in  Figure  3.  The 
application,  as  discussed  earlier,  uses  WebHub,  and  therefore  utilizes  the  broker/agent 
architecture.  The  application  resides  on  a  Windows  NT  Server.  The  main  components 
on  the  NT  Server  include  WebSite  Web  Server,  WebHub,  and  NPSD.exe  (Customized 
WebHub  WebApp).  The  business  logic  and  Locator  functionality  are  coded  into  the 
NPSD.exe  Delphi  program.  It  was  developed  using  the  WebHub  Web  Application 
framework. 


Figure  3.  NPS  Locator  Architecture 


The  other  major  component  is  the  data  store  for  the  Locator  data.  The  data  resides 
on  a  DEC  Alpha  workstation  running  Oracle  7.2  Database  Server,  with  two  main  tables, 
one  labeled  “main”  and  the  other  labeled  “register.”  The  structure  of  these  tables  can  be 
viewed  in  Appendix  A.  The  Locator  NT  Server  communicates  with  the  Oracle  Server  via 
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the  TCP/IP  NPS  Intranet.  More  specifically,  the  NPSD  program  uses  Borland’s  SQL 
Links  to  communicate  with  the  Oracle  database.  SQL  Links  in  conjunction  with  Oracle 
drivers  allows  full  connectivity  to  the  Oracle  Database  Server  from  any  Delphi  program 
utilizing  Borland’s  Database  Engine  (BDE). 

D.  FUNCTIONAL  DESCRIPTION 

This  section  describes  the  functional  operation  and  capabilities  of  the  NPS 
Locator  prototype.  When  possible,  various  screen-shots  of  the  prototype  will  be 
presented  to  aid  in  the  description  of  whatever  aspect  is  being  discussed  at  the  time.  The 
first  screen-shot  is  shown  below  in  Figured  It  is  the  main  page  of  the  Locator.  The 
options  available  to  the  user  at  this  point  are  “search,”  “login,”  and  “register.”  Each  will 
be  discussed  below. 


1.  Search 


The  search  feature  represents  the  real  purpose  of  the  directory  system.  The 
Locator  provides  a  basic  search  capability.  The  user  can  search  for  a  person  in  a  few 
different  ways,  usually  depending  on  how  much  information  the  user  already  has  about 
the  person  he  is  looking  for. 


Figure  4.  Locator  Homepage 
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Figure  5  shows  the  search  page  for  the  Locator.  The  user  has  the  option  to  use  a 
“first  letter”  search  by  selecting  the  appropriate  hyperlinked  letter  in  the  displayed 
alphabet.  This  will  generate  a  query  to  the  Locator  database,  which  will  return  all 
personnel  with  a  last  name  starting  with  the  selected  letter.  The  user  then  can  scroll 
through  the  records  to  find  the  name  he  was  looking  for. 


Figures.  Search  Screen 

For  a  more  narrow  search,  the  user  can  type  in  all  or  part  of  the  last  name  in  the 
appropriate  block  in  the  Advanced  search  dialogue.  The  search  is  not  case-sensitive.  The 
user  can  further  narrow  the  search  by  entering  in  a  department  code  and/or  the  employee 
type.  The  available  employee  types  are  faculty,  staff,  and  student.  The  department  code 
should  later  be  implemented  as  a  selection  box,  so  that  users  can  select  the  department 
code  without  confusion  of  what  should  be  entered,  and  to  prevent  spelling  errors. 

Once  a  user  a  has  initiated  a  search,  the  Locator  will  respond  with  the  search 
results  in  a  table  format  as  shown  in  Figure  6.  The  information  includes  last  name,  first 
name,  middle  initial,  title,  department,  mail  code,  phone  and  fax  number,  email,  and  a 
homepage  link.  If  the  person  has  an  email  account  at  the  computer  center,  then  his  or  her 
email  will  show  up  in  the  column,  and  it  will  be  hyperlinked.  The  hyperlinked  email 
will,  when  selected,  bring  up  the  user’s  mail  program  with  the  “to:”  block  filled  in  with 
the  email  address  selected  from  the  Locator.  If  a  person  has  a  homepage  at  the  computer 


Figure  6.  Search  Results 

center,  then  his  or  her  homepage  URL  will  be  listed  under  the  “Homepage”  column  and 
will  be  hyperlinked. 


The  last  name  column  is  hyperlinked  also.  When  it  is  selected,  it  displays  a  page 
that  provides  more  detailed  information  on  the  particular  person.  If  the  person  has 
registered  with  the  Locator,  then  there  may  be  additional  information  including  a  picture, 
if  the  person  chose  to  provide  it.  Figure  7  shows  what  the  detail  page  looks  like. 

2.  Register 

NFS  personnel  can  “register”  with  the  Locator  by  clicking  on  the  “register”  link 
on  the  home  page.  This  then  prompts  the  user  to  enter  his  last  name  so  the  Locator  can 
display  his  record.  Once  the  appropriate  record  is  found,  the  user  selects  his  record  by 
clicking  on  the  hyperlinked  last  name.  This  then  prompts  the  user  to  enter  in  an  email 
address,  which  will  serve  as  their  login  name.  The  email  address  is  also  used  by  the 
Locator  to  automatically  send  the  user  a  system-generated  password,  which,  when  used  in 
conjimction  with  the  login,  allows  entry  into  the  Locator. 
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Figure  7.  Search  Result:  Detailed  Listing 

If  a  user  is  not  in  the  system,  the  user  is  incorrectly  listed  in  his  or  her  respective 
data  source.  For  example,  a  student  not  listed  in  the  Locator  database,  in  most  cases,  is 
not  listed  in  the  Curricular  Officer’s  Database.  The  appropriate  action  by  the  user  would 
be  to  contact  his  Curricular  Office  and  verify  that  he  is  listed  correctly  in  the  database. 


3.  Login 


Once  a  user  is  registered,  he  has  the  ability  to  augment  tiie  system  generated 
information.  For  the  prototype  system,  a  user  can  upload  a  picture,  and  add  one 
additional  email  address  and  an  additional  URL,  both  of  which  will  be  hyperlinked. 
Finally,  the  user  can  add  information  in  a  text  box,  up  to  256  characters.  This  block 
should  be  used  for  information  that  enables  conununication  with  the  listed  person.  For 
example,  a  professor  may  place  his  class  schedule  and  available  officer  hours  in  this 
block.  A  staff  person  may  put  in  the  days  that  he  or  she  plans  to  take  leave.  As  a  final 
example,  a  student  may  put  in  his  thesis  study  area  so  that  others  may  locate  him. 
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rv.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  NPS  Locator  provides  a  simple,  interactive,  and  easy-to-use  facility  for  users 
to  access  useful  information  about  other  NPS  personnel.  The  Locator  successfully  ran  for 
two  months  during  a  test  in  the  NPS  computing  environment.  Updates  from  the 
Curricular  Officers’  database  and  from  the  CC  UNIX  accounts  were  successfully  merged 
and  uploaded  to  the  Locator  database.  This  database  provided  an  accurate  and  up-to-date 
resource  of  personnel  information  that  enabled  the  communication  and  location  of  NPS 
personnel.  In  addition,  the  Locator  allowed  a  user  to  augment  his  or  her  system  generated 
information  with  additional  information  to  further  enable  communications  between 
individuals. 

The  implementation  of  the  Locator  prototype  did  not  unveil  any  new  revelations 
for  those  in  charge  of  computing  at  NPS,  but  did  re-emphasize  some  of  the  current  issues 
NPS  is  struggling  with,  as  well  as  reinforce  the  benefits  of  Intranet  technology.  The 
explosive  growth  of  Web  technology  and  intranet  implementations  in  the  Corporate 
world  can  serve  as  a  testimonial  for  the  potential  of  intranets. 

The  benefits  that  NPS  can  obtain  from  intranet  technology  are  as  follows: 

•  The  Web  browser  is  a  universal  interface  that  allows  interoperability  in  NPS’s 
multiplatform  and  multi-NOS  environment. 

•  The  thin-client  architecture  of  intranet  applications  allows  NPS  to  use  fewer 
application  development  tools  and  eliminates  costly  multiplatform 
deployment  of  applications. 

•  Intranets  provide  a  fast  and  ubiquitous  information  distribution  platform  that 
faculty,  staff,  and  students  can  use. 

•  The  intranet’s  ease  of  updates  fosters  the  publishing  of  information  that  is 
more  accurate  and  up-to-date. 

•  Intranet  technology  is  relatively  cheap  which  is  important  in  the  times  of 
budgetary  constraints. 

Perhaps  the  real  value  of  the  implementation  of  the  NPS  Locator  prototype  lies  in 
its  emphasis  of  issues  plaguing  the  application  of  information  technology  at  NPS.  For 
example,  an  NPS  Phone  Book  application  was  developed  recently,  and  is  appropriately 
available  on  the  NPS  homepage.  The  directory  is  complete  and  is  easy  to  use.  Its  data 
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source  is  a  centralized  SQL  database  maintained  by  code  05.  Despite  its  accuracy  and 
timeliness,  many  organizational  units  still  have  their  own  Web  directory  on  their 
organizational  homepage.  The  information  in  these  directories  is  not  maintained  in  synch 
with  the  Code  05  database.  This  duplication  of  effort  and  lack  of  some  centralized 
management  will  hinder  the  success  of  an  effective  intranet  implementation  at  NFS. 

B.  RECOMMENDATIONS 

In  order  to  implement  any  directory  system  or  other  intranet  application  at  NFS, 
many  issues  must  be  dealt  with.  Some  of  the  issues  outlined  below  are  indeed  addressed 
in  the  recently  published  1997  draft  of  the  “Strategic  Flan  for  Computing  at  the  Naval 
Fostgraduate  School.”  The  issues  to  be  explored  are: 

•  There  is  a  need  for  a  centralized  personnel  database  that  contains  all  NFS 
personnel.  Code  05  has  developed  and  maintains  a  centralized  personnel 
database  that  currently  supports  the  new  accounting  system  and  the  NFS 
Fhonebook.  The  database  should  furflier  be  integrated  into  other  systems  as 
the  sole  source  for  personnel  information.  Folicy  should  be  enacted 
mandating  the  use  of  this  database  as  the  soxirce  for  all  personnel  information 
and  that  it  be  properly  maintained  as  such. 

•  All  NFS  personnel  should  have  an  account  or  alias  at  the  NFS  Computer 
Center.  This  provides  a  guaranteed  uniform  email  address  for  all  personnel  at 
NFS.  This  coupled  with  a  naming  standard  will  make  email  addresses 
derivable  just  by  knowing  a  person’s  name.  For  example,  if  the  standard  is  a 
concatenation  of  the  first  initial,  middle  initial,  and  the  first  six  characters  of 
one’s  last  name,  and  given  that  the  domain  for  NFS  is  nps.navy.mil  then 
deriving  an  individual’s  full  email  address  is  simple.  Jeffrey  E.  Forte  would 
hejeforte@nps.  navy.  mil. 

•  All  organizational  entities  should  have  an  organizational  mailbox.  An 
organizational  mailbox  is  not  associated  with  any  one  person  within  an 
organization.  It  allows  communication  with  the  organization  without  having 
to  know  someone  within  that  organization,  and  it  serves  well  as  a  method  for 
passing  official  messages.  Organizational  mailboxes  may  be  best 
implemented  as  hotlinks  on  an  organizational  chart. 

•  Support  should  be  demanded  for  centralized  management  of  the  computing 
infrastructure  that  is  balanced  with  distributed  control  within  organizational 
units.  The  Frovost  of  Computing  needs  to  have  support  from  the  highest 
authority  at  NFS,  and  a  method  for  enforcing  adherence  to  standards.  The 
right  balance  between  centralized  and  decentralized  control  and  areas  of 
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responsibilities  needs  to  be  explored  to  maximize  the  effectiveness  of  intranet 
implementation. 

•  An  NPS  data  dictionary  should  be  developed  for  all  informational  entities  and 
attributes.  Sometimes  it  is  not  practical  to  use  one  centralized  database  for  all 
applications  because  of  performance  issues,  security  restrictions,  or 
communication  limitations.  It  would  be  advantageous  to  record  all 
information,  despite  how  it  is  used,  in  a  uniform  and  predictable  manner.  For 
example,  many  of  the  databases  reviewed  as  potential  databases  for  die 
Locator  stored  the  elements  of  a  person’s  name  in  very  different  ways.  The 
Curricular  database  stored  the  name  as  one  field,  separating  the  last  name  and 
first  name  by  a  comma.  Other  databases  had  the  usual  breakout  of  the  name 
into  its  three  components — first,  middle,  and  last  names.  The  use  of  a  data 
dictionary  allows  for  any  possible  future  exchanges  of  information  with  any 
information  store  to  be  compatible  with  respect  to  the  format  of  the  individual 
data  elements. 

•  Consideration  should  be  given  to  the  creation  of  a  unique  identifier  for  each 
person  at  NPS.  This  would  allow  the  use  of  this  id  as  a  unique  index  key  to 
individuals  without  the  possibility  of  compromising  privacy  by  use  of  die 
social  security  number.  Furthermore,  any  time  information  is  recorded  on  an 
individual,  password  files  included,  this  unique  id  should  be  recorded  as  well. 

•  NPS  should  conduct  a  survey  of  commercial  directory  systems  for  NPS  use. 
Many  vendors  are  offering  directory  systems  that  allow  customization,  and 
most  of  them  provide  a  single  login  and  password  for  access  to  all  network 
resources  from  anywhere  on  the  network.  Banyan’s  StreetTalk  for  NT  and 
Novell’s  NDS  for  NT  are  two  popular  offerings. 

Any  tool  is  effective  only  if  used  appropriately.  Intranets  are  no  exception. 
Technology  is  only  half  of  the  solution;  management  is  the  other  half.  If  a  synergy  exist 
between  these  two  elements,  an  intranet  can  help  harness  the  potential  of  an  organizations 
information  technology. 
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(HARVEST  Module) 

unit  ftph1; 

interface 

uses 

Windows,  Messages,  SysUtils,  Classes,  Graphics,  Controls,  Forms,  Dialogs, 
StdCtrls,  OleCtrls,  NMCT,  ExtCtrls,  ComCtrls,  ISP; 

type 

TFormI  =  class<TForm) 

FTP:  TFTP; 

Timerl:  TTimer; 

Status:  TStatusBar; 

Label 1:  TLabel; 

procedure  FTPAbortC Sender:  TObject); 
procedure  FTPExecuteC Sender:  TObject); 
procedure  FT PNoop< Sender:  TObject); 

procedure  FTPS tateChangedC Sender:  TObject;  State:  Smallint); 
procedure  Download(  const  getFile,putFi le: string); 
procedure  Timerl Timer (Sender:  TObject); 
procedure  FormActivateC Sender:  TObject); 

procedure  FormC I ose( Sender:  TObject;  var  Action:  TCloseAction); 
procedure  UaitToAl louProcessing; 


private 

<  Private  declarations  > 
public 

<  Public  declarations  > 
end; 

var 

Formi:  TFormI; 
implementation 
C$R  *.DFM> 
var 

LogStr:TStringList; 

const 


cRemoteKost 

*131.120.50.206*; 

cPort 

= 

*21'; 

cUser 

= 

*  locator*; 

cPass 

*2nttk4u*; 

cFi leToGetl 

= 

'userlist.txt*; 

cFileToGet2 

= 

•currf ill. data*; 

cFileToGetS 

= 

*currfil2.data*; 

cDataDir 

*  c : \thes i s\npsd\ * ; 

cFileTeWritel 

CDataDir  +  cFileToGetl; 

cFileToWrite2 

cDataDir  +  'curric1.txt 

cFi leToWrite3 

= 

cDataDir  +  'curric2.txt 

cLogDir 

= 

*c:\temp\*; 

procedure  TFormI -FTPAbortC Sender:  TObject); 
begin 

LogStr.addC 'abort  event*); 

<WANT  TO  WRITE  OUT  TO  A  LOO 
end; 

procedure  TFormI. FTPExecuteCSender:  TObject); 
begin 

LogStr.add  (  'execute'); 

end; 

procedure  TFormI -FTPNoop(Sender:  TObject); 
begin 


41 


LogStr.addC  *Noop*  ); 


end; 


procedure  TFormI .FTPStateChanged( Sender:  TObject;  State:  Smallint); 
begin 

with  FTP,  LogStr  do 
case  State  of 

prcConnect i ng  :  add( *  Connect i ng  * ) ; 

prcResolvingHost:  add( "Connecting* ); 
prcHostResoLved  :  add(*Kost  resolved*); 
prcConnected  :  add(* Connected  to:  »  +  RemoteHost); 
prcD i sconnect i ng :  add( ' D i sconnec t i ng • ) ; 
prcDisconnected  :  add( "Disconnected*); 


end; 


end; 


procedure  TFormI .Down I oad(  const  getFile,putFile:string); 
begin 

Status.simpLeText:=  'Downloading  *  +  getFile  +  *  ---*; 
if  (FTP.protocolstate  <>  2)  then  begin 

LogStr. add( 'Transfer  Aborted!*);  //  do  abort  recovery... email 

//  notification  and  Logging? 
end 

else  begin 

UaitToAl lowProcessing; 

LogStr . add( i nttost r( FTP . protocol state) ) ; 

FTP. GetFile  (getFile,  putFile); 

//  give  it  a  chance  to  get  info 
Wai tToA 1 1 owProcess i ng ; 

while  ( FTP. docout put -State  <>  5)  do  begin 
application.ProcessMessages; 
if  FTP. docoutput. state  =  A  then  break; 
end; 

LogStr. add(FloatToStr(FTP.docoutput-bytestotal)  +  *  bytes  total  transfered  to  file  * 
+  putFile); 


end; 

end; 

procedure  TFormI .  Timer  1  Timer  (Sender:  TObject); 
begin 

timerl, interval  :=  5000; 
timerl .enabled  :=  false; 
end; 


procedure  TFormI -FormActi vat e( Sender:  TObject); 
begin 

LogStr  :=  TStringList. create; 

Status. simpleText:=  'Connecting  to  *  +  cRemoteHost  +  '  ...*; 

FTP . connect ( cRemoteHost , cPor t ) ; 

While  (FTP. State  =  1)  Or 
(FTP. State  =  2)  Or 

(FTP. State  =  3)  do  Application.ProcessMessages; 

While  (FTP. State  =  A)  And  (FTP.ProtocolState  =  0)  do  Af^lication.ProcessMessages; 

//  Wait  For  Connection  Response 
//  Wait  for  status  change... 

//  Check  Status  Of  Control 

Status. simpleText:=  'Authenticating  User:  '  +  cUser  +  *  -..*; 

FTP. authenticate  (cUser,cPass); 

//LogStr .add(  i nttost r( FTP.protocolstate) ) ; 

Status. simpleText:s  'Deleting  old  files... *; 

Wa i tToA 1 1 owP rocess i ng; 
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DeleteFi le(cFi leToWritel ); 

DeleteFi le(cFi leToWrite2); 

DeleteFi le(cFi leToWriteS); 
downloadCcFi  leToGetl  ,cFi  leToWriteD; 
download(cFi leToGet2,cFileToWrite2); 
downloadCcFi leToGet3,cFi leToWriteS); 

FTP.quit; 

Forml.close; 

end; 

procedure  TForml.FormC I ose< Sender:  TObject;  var  Action:  TCloseAction); 
var  F: text File; 

FileName:string; 

begin 

fileName  :=  cLogDir  +  *  FTP. log'; 

AssignFi le(F,  FileName); 

ReWrite(F); 

WritelnCF,  'FTP  Log  on  »  +  dateTimeToStr(now)); 

WritelnCF,  Logs tr. text); 

CloseFile(F);  <  Close  file,  save  changes  > 


procedure  T F orm1 . Wa i t T oA 1 1 owP r ocess i ng; 
begin 

timerl -enabled  :=  true; 

while  (timerl. enabled  =  true)  do  application.ProcessMessages; 
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(MERGE  Module) 

unit  mergel; 

interface 

uses 

WirKdows,  Messages,  SysUtils,  Classes,  Graphics,  Controls,  Forms,  Dialogs, 
Grids,  DBGrids,  StdCtrls,  OBTables,  DB,  libcrypt,  ComCtrls,  ExtCtrls; 

type 

TFormI  =  class(TForm) 

AsciiTable:  liable; 

BatchMovel :  TBatchMove; 

Table2:  liable; 

Table3:  liable; 

Queryl:  IQuery; 

Query2:  IQuery; 

Iable4:  Ilable; 

Databasel:  IDatabase; 

Main:  liable; 

Query3:  IQuery; 

LabeH:  ILabel; 

Status:  IStatusBar; 

Imagel:  Ilmage; 

procedure  ConvertlxtFi lesIoDBs; 
procedure  CleanCurricData; 

function  RemFirstField(ch:char;  var  s:string):string; 
procedure  MergeCurricWithEmai lUrlData; 

procedure  FormC I ose( Sender:  lObject;  var  Action:  ICloseAction); 
procedure  OracleBatchUpdate; 
procedure  DeleteStudentsFromMain; 
procedure  FormActivateC Sender:  lObJect); 


private 

<.  Private  declarations  > 
public 

Public  declarations  > 

end; 

var 

Formi:  IFormI; 
implementation 
fSR  *.DFM> 
const 

cDataDir  =  ‘CrMhesisXnpsdX* ; 

procedure  IFormI -ConvertlxtFi lesIoDBs; 
begin 

app I i cat i on . P  r ocessMessages ; 
try 

Status,  sir^  I  el  ext  :=  'Converting  Curricular  Extract  Filed)'; 
with  asciilable  do  begin 
close; 

databasename  :=  cDataDir; 
tabletype  :=  ttascii; 
tablename  :=  'curric2.txt'  ; 
active  :=  false; 
end; 

with  BatchMovel  do  begin 
Source:=asci liable; 
table2.close; 

t ab I e2. databasename  :=  cDataDir; 
table2-tableName:='phase1 ' ; 

Destination:=table2; 
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Mode :=bat append; 

AbortOnKeyViol  :=  False; 

KeyViolTableName  :=  cDataDir  +  »KEYVIOL1.DB*; 
t ab I e2 . EmptyT ab I e ; 
execute; 
table2. close; 
table2.  open-¬ 
end; 

Status,  simp  I  eText  :=  'Converting  Curricular  Extract  Filed)*; 

//  MessageDlg(IntToStr(batchmove1 .MovedCount)  +  •  records  read*-  mt Informat ion-  CmbOK] -  0); 
Stat us. simpl eText  :=  I ntToStrC bat chmovel .MovedCount)  +  *  records  read!  --*  + 

*Now  Converting  Curricular  Extract  File(2)'; 
appl i cat i on. ProcessMessages ; 

with  asciiTable  do  begin 
close; 

databasename  :=  cDataDir; 
tabletype  :=  ttascii; 
tablename  :=  'curric1.txt*; 
active  :=  false; 
end; 


with  BatchMovel  do  begin 
Source: =asci i Table; 
tabl e3. close; 

table3. databasename  :=  cDataDir; 
table3.tableName:=*Phase2*; 

Dest i nat i on : =tab I e3; 

Mode : -batappend; 

AbortOnKeyViol  :=  False; 

KeyViolTableName  ;=  cDataDir  +  'KEYVIOL2.DB*; 
table3.EmptyTable; 
tab I e3. open; 
execute; 
tabl e3. open; 
end; 

//  MessageD lg( I ntToStr(batchmove1 .MovedCount)  +  *  records  read',  mt Informat ion,  [mbOK],  0); 
Status. simpl eText  :=  I ntToStr(batchmove1 .MovedCount)  +  *  records  read!  --*  + 

*Now  Converting  UNIX  System  Extract  File*; 
appl i cat ion. ProcessMessages ; 

with  asciiTable  do  begin 
close; 

databasename  :=  cDataDir; 
tabletype  ttascii; 
tablename  :=  'userlist.txt*  ; 
active  :=  false; 
end; 

with  BatchMovel  do  begin 
Source: sasci i Table; 
table2. close; 

table2.tableName:=*Phase4a* ; 

Dest i nat i on: =tabl e2; 

Mode : =batappend; 

AbortOnKeyViol  :=  False; 

KeyViolTableName  :=  cDataDir  +  *KEYVIOL4a.DB»; 
table2 . EmptyTabl e; 

//table2.open; 

execute; 

//table2.open; 

end; 

//  MessageDlg<IntToStr(batchmove1 .MovedCount)  +  *  records  read*,  mt Informat ion,  [mbOK],  0); 
Status -simp I eText  :=  I ntToStr(batchmove1 .MovedCount)  +  '  records  read!  + 

*Now  Eliminating  Duplicates  in  UNIX  System  Extract*; 
appl i cat i on . ProcessMessages ; 
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with  BatchMovel  do  begin 
Source:=Table2; 
tab I e4. close; 

table4.databasename  cDataDir; 
tabl e4 . tabl eName : = ' PhaseAb ' ; 
tabled. tabletype  :=  ttparadox; 

Dest i nat i on: =tabl e4 ; 

Mode : =bat append; 

AbortOnKeyViol  :=  False; 

KeyViolTableName  :=  cDataDir  +  *KEYVIOL4b-DB*; 

table4.EmptyTable; 

execute; 

end; 

Status. simpler ext  :=  IntToStr(batchmove1 .MovedCount)  +  '  records  read!*; 

application.ProcessMessages; 

except 

asc i liable. cl ose; 
table2.close; 
table3.close; 
table4. close; 
halt; 
end; 
end; 


procedure  T  F o r ml . C I eanCur  r i cD a t a ; 
var 

first, second, third, fourth, temp:  String; 
i,size,cnt:  integer; 
exist comma:  boolean; 

begin 

Status. simpler ext  :=  'Cleaning  Curricular  Extract  DAIA*; 

appl i cat i on. ProcessMessages ; 

queryl. close; 

query 1 .open; 

queryl .first; 

with  Table2  do  begin 
close; 

DatabaseName  :=  cDataDir; 
tableName:= *  phase3 » ; 

Empty! able; 
end; 

rable2.open; 

while  not  Query I.Eof  do  begin 
rable2.append; 


temp  :=  UpperCaseCIrirnCQueryl .fieldbyname( *  name* ). asst ring)); 
size  :=  Length(temp); 
cnt  0; 

existcomma  :=  false; 

For  i  :=  1  to  size  do  begin 
if  tempti]  =  *,*  then 
existcomma  :=  true; 

end; 

if  (existcomma)  then  begin 

Table2[*Last*)  RemFirstFieldC * , * ,temp); 
t^  :=  trim(temp); 
size  :=  Length (temp); 

For  i  :=  1  to  size  do  begin 
if  tempEi)  =  *  *  then 
inc(cnt); 

end; 


case  cnt  of 
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0:  begin 

Tables C* First*]  ;=  temp; 

end; 

1:  begin 

Tables t* First*]  :=  RemFirstField( *  »,temp); 

TableSC'Middle*]  :=  temp; 

end; 

else  begin 

Tables ['First*]  :=  RemFirstFieldC »  *,temp); 

TableS[*Middle*] :=  RemFirstFieldC  *,temp); 

end; 

end; 

end 

else  begin  //no  comma 

For  i  :=  1  to  size  do  begin 
if  tempti]  =  *  *  then 
Inc(cnt); 

end; 

first  :=  *'; 
second  ;=  **; 
third  :=  **; 
case  cnt  of 
0:  begin 

Tables ['Last*]  :=  temp; 

end; 

1:  begin 

Tables ['Last*]  :=  RemFirstFieldC*  »,temp); 

TableSC'First*]  :=  temp; 

end; 

S:  begin 

first  :=  RemFirstFieldC*  ',temp); 
second:=  RemFirstFieldC*  *,tefnp); 
third  :=  trimCtemp); 

if  CCfirst  =  *AL*)  or  [first  =  *VAN')  or  [first  =  *V0N*))  then  begin 
Tables ['Last']  :=  first  +  second; 

TableSC'First*]  :=  third; 
end 

else  begin 

Tables ['Last*]  :=  first; 

Tables [* Fi rst *] :=  second; 

TableS[*Middle*]  :=  third; 
end; 


end; 

else  begin 

first  :=  RemFirstFieldC*  *,temp); 
second: =  RemFirstFieldC*  *,temp); 
third  :=  trimCRemFirstFieldC*  *,temp)); 

if  ([first  =  *AL»)  or  (first  =  'VAN*)  or  (first  =  *V0N*))  then  begin 
Tables ['Last*]  :=  first  +  second; 

TableS[*First*]  :=  third; 

end 

else  begin 

TableSC'Last*]  :=  first; 

TableS[*First*] :=  second; 

TableS[*Middle*]  :=  third; 
end; 

end; 

end; //case 

end;  //  if -else  comma  test 

TableS[*Id*]  :=  copy(crypt(Queryl [*ssn*] ,  **$*>,3,11)+  copy(Query1 [»ssn*] ,9,1); 
Tables ['Mailcode']  :=  Queryl [*mai Icode*] ; 

Tables ['Dept *]  :=  Query1[*Dept']; 

Tables ['Phone']  :=  Queryl [* Phone *] ; 

TableS[*Title*]  :=  'Student:  *  +  Queryl [*curr*]  +  *  curriculum*; 

Tables ['Status']  :=  'STUDENT*; 

Tables. post; 
queryl. next; 
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end; 

Table2. Closed- 
Table?,  open; 


end; 


function  TFormI .RemFi rst Fie ld(ch: char;  var  s:string):string; 
var 

idSize  :  Integer; 
s2  :  String; 
begin 

Setlength(s2,255); 
i:=  pos(  chdS); 

If  i  =0  then  begin 
RemFirstField  :=  s; 

Exit; 

end; 

size  :=  (length(s)-l ); 

Move(s[i+1]d  s2[1]d  size); 

Setlength(Sdi-l); 

Setlength(s2dSize); 

RemFirstField  :=  s; 
s:=  s2; 

end; 

procedure  TFormI .MergeCurricWithEmai lUrlData; 
var 

I,initcountdful Icountd  nomatchdf irstcount:  integer; 

LookUpResu I ts : var i ant ; 

LuLastdLuFirst,LuMiddle,  LuFinitd  LuMinit,LuLFM:  string; 
begin 

//  AT  THIS  POINT  WE  WANT  TO  MERGE  WITH  THE  PERL  FILE  TO  GET  EMAIL  AND  URL 

//****^************************  ^  URL/Email  data  with  Phase3  product 

Status. simpleText  :=  'Merging  Curricular  Extract  DATA  with  UNIX  Extract  DATA*; 
appl i cat i on. ProcessMessages; 

Tables. close; 

Tables. databasename  :=  cDataDir; 

Tables. tab I ename  :=  *phase4b.db'; 

Tables. open; 

Tables. first ; 

Table?. open; 

Table2-f irst; 
initcount:=0; 
fullcount:=0; 
firstcount:=0; 
nomatch  :=0; 

while  not  table?. eof  do  begin 

LuLast  :=  Trim(Table?.f ieldbynameC 'Last* ) .asstring); 

LuFirst  Trim(Table?.fieldbyname(* First*). asstring); 

LuMiddle:=  Table?.f ieldbynameC 'Middle* ). asstring; 

LuFinit  :=  copy(LuFirst,1d1); 

LuMinit  :=  copy(LuMiddled1,1); 

LuLFH  :=  LuLast  +  LuFinit  +  LuMinit; 

if  Tables. LocateC  *Lname;Fname;MI * , 

VarArrayOfC [LuLast, LuFirst, LuMinit] )dCloPartialKey])  then  begin 
Table?. edit; 

Table?[*efnail*]  :=  Tables  ['email']  +  'anps.navy.mi  I  *; 

Table?['url*]:=  TableS[»url*]; 

incCfullcount); 

table?. post; 


end 

else  if  Tables. LocateC 'LastFiMi ', LuLFM,  [loCaseInsensitive,loPartialKey]  )  then  begin 
Table?.edit; 

Table?['emai I ']  :=  TableSC'emai I']  +  'Qnps.navy.mi I *; 
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TabLe2[*url*]:=  Table3['url*]; 
table2.post; 
incCinitcount); 
end 

else  if  Table3.LocateC 'Lname;Fname* , 

VarArrayOfC  CLuLast,LuFirst] ), [loPartialKey] )  then  begin 
Table2.edit; 

Table2['emai I ']  :=  Table3['efnai I ']  +  *anps.navy.mil *; 
Table2[»url*]:=  Table3E*url']; 
table2.post; 
inc(firstcount); 
end 
else 

inc(nomatch); 

if  table2.fieldbyndme( ‘middle' ).asString  <>  '*  then  begin 
table2.edit; 

table2 [‘middle*]  :=  copy(table2.f ieldbyname( 'middle‘).asString,1,1); 
table2.post; 

end; 

table2.next; 


end; 


end; 


procedure  TFormI -FormClose(Sender:  TObject;  var  Action:  TCloseAction); 
begin 

asciiTable. close; 
table2. close; 
table3. close; 
table4. close; 
end; 


procedure  TFormI -OracleBatchUpdate; 

var  I: char; 

begin 

Status.simpleText  :=  ‘Updating  Oracle  Database*; 
appl i cat i on. ProcessMessages; 
for  I  :=‘A*  to  ‘Z‘  do  begin 

Status.simpleText  :=  'Updating  Oracle  Database  w/  Last  names  beginning  with:  ‘  +1; 
QUERY3.CL0SE; 

QUERY3. SQL. CLEAR; 

QUERY3.SQL.ADD(‘ INSERT  INTO  '':LOC:MAIN"  SELECT  *  ‘  + 

‘FROM  ":NPSD:PHAS£3"  WHERE  LAST  LIKE  »+  iim  +  |  +  i%iii); 

QUERY3.EXECSQL; 

appl i cat i on. ProcessMessages; 

end; 

QUERY2.CL0SE; 

QUERY2 . SQL . CLEAR * 

QUERY2.  SOL  .ADD  ('UPDATE  MAIN  M  SET  REGISTERED-"!"  WHERE  M.ID  -  ' 

•(SELECT  FKID  FROM  REGISTER  R  WHERE  M.ID=R.FKID  )•); 

QUERY2.EXECSQL; 

appl i cat i on .ProcessMessages ; 


procedure  TFormI .DeleteStudentsFronMain; 

var  s:string; 

begin 

//  The  runs  a  delete  query  on  the  Main  table... it  deletes  all  student  records. 
//  The  query. sql. text  =  '  DELETE  FROM  "MAIM"  WHERE  "Status"  =  'STUDENT'  • 
Status.simpleText  'Deleting  Old  Student  Data'; 
appl i cation. ProcessMessages; 

QUERY2. CLOSE ; 

QUERY2.S0L.CLEAR; 

Query2. sql. add( 'DELETE  FROM  MAIN  WHERE  STATUS-"  STUDENT  •"  ); 
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Query2.execsql; 
que ry2. close; 
end; 

procedure  TFormI .FormActivate(Sender:  TObject); 
begin 

ConvertTxtFi lesToDBs; 

CleanCurricData; 

MergeCurricWithEmai lUrlData; 
DeleteStudentsFromMain; 

0 r ac I eBa t chUpda t e ; 

App I i cat 1  on . Term! na te; 


end. 

end. 
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APPENDIX  C.  NPS  LOCATOR  MAIN  SOURCE  CODE  MODULE 


This  Appendix  contains  the  main  module  of  the  NPS  Locator  Prototype.  This  module 
provides  all  the  business  logic  and  Web  application  functionality. 


unit  NPSf; 

interface 

uses 

SysUtils,  Messages,  Classes,  Graphics,  Controls,  Forms,  Dialogs 
,  Buttons,  StdCtrls,  Menus,  ExtCtrls 
CSIFDEF  WIN32> 

,  Windows 
<:$ELSE> 

,  UinProcs,  WinTypes 
C$ENDIF> 

,  Toolbar 

,  TpMenu,  TpMemo,  UebMemo,  Combobar 
,  WebTypes,  WebVars,  UebBase,  UebCore,  WebApp,  UebCall 
,  Uebmenu,  HtmlBase,  NtmlCore,  HtmlSend,  Webinfo,  WebBrows, 

UpdateOk,  UeblniFL,  UebHttp,  UebServ,  IniLink,  Uebconst 
,WebForm,  Restorer,  TpApplic,  TpLabel,  WebLink,  WebPage,  WebPHub,  DB, 
DBTables,  UdbLink,  WdbScan,  UdbGrid,  UdbSorce,  DBCtrls,  Grids,  DBGrids, 
TblRetry,  Uebtbl,  UebMail,  WebSock,  ucstring; 

type 

TWebAppNPS  =  class(TUebAppForm) 

StatusBarl:  TtpStatusBar; 

StatusPanell:  TtpStatusPanel; 

UebAppOutput:  TUebAppOutput; 

Uebinfo;  TWebInfo; 

UebI ni F i leL i nk :  TWebI ni F i leL i nk; 

Webserver:  TWebServer; 

WebBrowser:  TWebBrowser; 

WebConmandL  i  ne1 :  TWebCommandL  i  ne; 

WebAppNPS:  TWebApp; 

UebSessionO:  TWebSession; 
tpComponen t Pane 1 1 :  T  t pComponentPane I ; 
tpAppRolel:  TtpAppRole; 

FormRestorerl :  TFormRestorer; 

DoMenuBarFile:  TtpDfmMenuItem; 

DoExit:  TtpDfmMenuItem; 

DoMenuBarHelp:  TtpDfmMenuItem; 

DoContents:  TtpDfmMenuItem; 

DoTopicSearch:  TtpDfmMenuItem; 

DoHowtouseHelp:  TtpDfmMenuItem; 

DoTtpDfmMenultem:  TtpDfmMenuItem; 

DoAbout:  TtpDfmMenuItem; 

DoAct i onComponents :  TtpMenuI tern; 

DoWebPages:  TtpMenuI tern; 

WebMenul:  TWebMenu; 
tpComboBarl:  TtpComboBar; 

ToolBar2:  TtpToolBar; 

DoMenuItemView:  TtpMenuItem; 

DoMenuItemTool:  TtpMenuItem; 

DoMenuItemVerb:  TtpMenuItem; 

DoMenultemIdle:  TtpMenuItem; 
tpT 00 1 Buttons rowser :  T tpToo I Button; 
tpToolButtonMemo;  TtpToolButton; 
tpToolButtonActivated:  TtpToolButton; 
tbBlankPage:  TtpToolButton; 
tbUserPage:  TtpToolButton; 
tbMemoPage:  TtpToolButton; 

Notebook:  TNotebook; 
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WebHtmlMemol :  TWebHtmlMemo; 
tpLabell:  TtpLabel; 
tpLabel2:  TtpLabel; 

SurferTbl:  TTable; 

DataSourcel :  TDataSource; 

UebOataSourcel :  TUebDataSource; 

Queryl:  TQuery; 

BatchMovel :  TBatchMove; 
registertbl:  TTable; 

NPS  ANSWER:  TUebPage; 

NPS_DETAIL:  TWebPage; 

DBGridl:  TDBGrid; 

DBNavigatorl :  TDBNavi gator; 
wgridl:  TWebDataGrid; 

NPS_ADMIN:  TWebPage; 

Editl:  TEdit; 

Memol:  TMemo; 
wgrid2:  TWebDataGrid; 

NPS  ANSWERREG:  TWebPage; 

NPS_DETAILREG:  TWebPage; 

WebSockI:  TWebSock; 

WebMaill:  TWebMail; 

NPS_FBREGISTER:  TWebPage; 

DataSource2;  TDataSource; 

NPS^DETAILLOG:  TWebPage; 
main:  TTable; 

NPS  FBUPDATE:  TWebPage; 

NPS^HOMEPAGE:  TWebPage; 

NPS_LOGINPG:  TWebPage; 

NPS  FBUPLOADPIC:  TWebPage; 

NPS^UPLOADPIC:  TWebPage; 

NPS_LOGUPDATE:  TWebPage; 

NPS_CHGPASS;  TWebPage; 

NPS^FBCHGPASS:  TWebPage; 
npsd:  TDatabase; 

procedure  Se I ectPageC Sender:  TObject); 
procedure  FormCreateC Sender:  TObject); 
procedure  Query1After0pen(DataSet:  TDataSet); 
procedure  6rid1HotField(Sender:  TWebDataScan;  aField:  TField; 
var  s:  string); 

procedure  Grid2HotField( Sender:  TWebDataScan;  aField:  TField; 
var  s:  string); 

procedure  Query1Before0pen( DataSet:  TDataSet); 
procedure  NPS_ANSWERSection(Sender:  TObject;  Section:  Integer; 
var  Chunk,  Options:  string); 

procedure  WebAppNPSEventMacro(Sender:  TWebOutputApp;  const  aMacro, 
aParams,  alD:  string); 

procedure  NPS_DETAILSection(Senderr  TObject;  Section:  Integer; 
var  Chunk,  Options:  string); 

procedure  NPS_ANSWERREGSection( Sender:  TObject;  Section:  Integer; 
var  Chunk,  Options;  string); 

procedure  NPS_DETAILREGSection(Sender:  TObject;  Section:  Integer; 

var  Chunk,  Options:  string); 
procedure  NPS_FBREGISTERExecute<Sender:  TObject; 
var  Continue:  Boolean); 

procedure  NPS_DETA I LLOGSection( Sender:  TObject;  Section:  Integer;  var  Chunk, 
Options;  string); 

procedure  NPS_DETA I LLOGExecuteC Sender:  TObject;  var  Continue:  Boolean); 

procedure  NPS_FBUPDATEExecuteC Sender:  TObject;  var  Continue:  Boolean); 
procedure  NPS_HOMEPAGEExecute( Sender:  TObject;  var  Continue:  Boolean); 
procedure  NPS^LOG I NPGExecDone( Sender:  TObject); 
procedure  NPS_HOMEPAGESection( Sender:  TObject;  Section:  Integer; 

var  Chunk,  Options:  string); 
procedure  NPS_FBUPLOADP I CExecute( Sender:  TObject; 
var  Continue:  Boolean); 

procedure  NPS^UPLOADP I CExecute( Sender:  TObject;  var  Continue;  Boolean); 
procedure  NPS_LOGUPDATESection(Sender:  TObject;  Section;  Integer; 
var  Chunk,  Options:  string); 

procedure  NPS_LOGUPDATEExecute( Sender;  TObject;  var  Continue:  Boolean); 
procedure  NPS^FBUPLOADP I CSection( Sender:  TObject;  Section:  Integer; 
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var  Chunk,  Options:  string); 

procedure  NPS_CHGPASSExecute( Sender:  TObject;  var  Continue:  Boolean); 
procedure  NPS_FBCHGPASSExecute(Sender:  TObject;  var  Continue:  Boo lean) ; 

private 

i  Private  declarations  > 

function  getNextDBFi lename:String; 

procedure  SetSurferDbCTbl :TTable); 

procedure  SetDBEnv(Tbl:TTable); 

function  GeneratePassword  : string; 

function  GetLitera I (Literal Name  : string): string; 

function  GetFormLiteraKLiteralName  :string):string; 

Procedure  Put L i tera I ( L i tera I Name , L i t era I Va I ue : st r i ng ) ; 
procedure  Bounce! o( Page I D : s t  r i ng ) ; 

{upload  utilities} 
procedure  UpLoadUserFi les; 

procedure  SaveUploadFi le(const  UploadInfo:string; 

var  NeuF i leName, C I i ent F i I eName : St r i ng ) ; 
procedure  ForceFileRenameCconst  oldName,newName:string); 
public 

<  Public  declarations  > 
end; 

var 

WebAppNPS:  TUebAppNPS; 
implementation 
{SR  *.DFM> 


{ . > 

var 

next TempNum: integer;  {  used  to  cycle  thru  temp  table  names  > 

initFlag:  Boolean;  {  flag  for  use  with  temporary  workaround  > 


const 

maxS i mu IQuer i es=25 ; 
cPageldFrontDoor  =  ‘homepage^; 
cUebSvrDir  =  * C:\Websi te\htdocs\‘; 
cImageDir  =  cUebSvrDir  +  *npsd\img\*; 
cDat aD 1 r  =  • C : \Thes i s\npsd\ * ; 


{ . > 

procedure  TWebAppNPS.FormC reate (Sender:  TObject); 
begin 

Se I ectPage( tbB I ankPage) ; 
end; 

{ . > 

procedure  TWebAppNPS. Se I ectPdge( Sender:  TObject); 
begin 

with  TtpToo I But ton( Sender)  do  begin 
NoteBook . Page I ndex : =Tag ; 

Down :=T rue; 
end; 
end; 

function  TWebAppNPS. getNextDBFi lename:String; 
begin 

i nc ( Next TempNum ) ; 

if  NextTempNum>maxSimulQueries  then  NextTempNum:=1; 
resu  1 1 : = *  qry  * + i  ntToSt  r  ( NextTempNum)-)-  * .  db  * ; 
end; 

procedure  TWebAppNPS, Query1After0pen(DataSet:  TDataSet); 
begin 

with  BatchMovel  do  begin 
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Source:=Query1; 

SurferTbl.close; 

SurferTbl  ,tableName:=getNextDBFi  lename; 

Destfnation:=SurferTbl; 

Mode :=bat Copy; 

execute; 

queryl.close; 

SurferTbl-open; 

end; 

UebAppNPS.LiteraU'DBName*]  :=  SurferTbl  .tablename; 

SetDbEnvC SurferTbl ) ; 
end; 

proc^ure  TWebAppNPS.Grid1HotField(Sender:  TWebOataScan; 

aField:  TField;  var  s:  string); 
var 

desc  :  string; 
g:TWebDataGrid; 

tc:TDataSet;  i  tc  stands  for  Table  Cursor,  a  bit  of  a  trad  from  ObjectPal  > 
idiString; 
begin 

desc  :=  aField. asString; 

g:=TWebDataGrid(Sender);  C  so  we  can  reuse  this  proc  for  multiple  grids  > 

tc:=aField.DataSet; 

id:stc.f ieldByNameC  ‘Id*  ). asString; 

CJUMP  is  a  built-in  WebHub  macro.  Syntax  is:  JUMP  |  pagel  d,  command  |vi  sib  I  ePh  rase  > 
if  compareTextCaField.fieldName,  *Email»)=0  then 

s:=*<TD><A  HREF=mai Ito: ■  +  afield. asstring  +  *>*  +  afield. asstring 
+  *  </A>/TD>* 

else  if  compareTextCaField.fieldName,  »Last')=0  then 

s:=*<TD>*  +  •%=JUMP|detai I, *+  id  +  'j*  +  desc  +*=%* 

else 

s:=  *<TD><A  HREF  =  *  +  afield. asString  +  *>*  +  afield. asString  +  *</A>/TD>*; 


end; 


proc^ure  TWebAppNPS.Grid2HotField(Sender:  TWebOataScan; 

aField:  TField;  var  s:  string); 
var 

desc  :  string; 
g:TWebDataGrid; 

tc:TDataSet;  <  tc  stands  for  Table  Cursor,  a  bit  of  a  trad  from  ObjectPal  > 
id:String; 
begin 

desc  :=  aField. asstring; 

g:=TUebOataG ride Sender);  <  so  we  can  reuse  this  proc  for  multiple  grids  > 

tc:=aField. DataSet; 

id:=:tc.f ieldByNameC  *Id*  ).asString; 

<JUMP  is  a  built-in  WebHub  macro.  Syntax  is:  JUMP | pagel d,coninand I visiblePh rase  > 
if  CompareTextCaField.fieldName,  *Last*)=0  then  begin 
if  notCtc.fieldbynameC'Registered*). value  =  *1*)  then 
s:=*<TD>»  +  ■%=JUMP|detailreg,  id  +  *|*  +  desc  +  •=%* 
else 

s:='<TD>**  +  desc; 
end 
else 

s:=  *<TD><A  HREF  =  *  +  af ield.asString  +  *>»  +  afield. asString  +  *</A>/TD>«; 

end; 


procedure  TWebAppNPS.QuerylBeforeOpenCDataSet:  TDataSet); 
var  srchkeys :  i  nteger  ; 
tokrstring; 

begin 

tok  :=  *%*; 
srchkeys  :=  0; 

with  TQueryC  DataSet  )  do  begin 
sql .clear; 

sql.addC  'SELECT  *  FROM  MAIN*  ); 
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if  WebAppNPS.WebServer.FormLiterals.ValuesC'Last*]  <>  **  then  begin 
sql.addC  >UHERE  Last  LIKE  '); 

sql.addC*  "  '  uppercase(UebAppNPS.UebServer. FormLiterals.ValuesC* Last tok 

•III). 

inc(srchkeys); 

end; 

if  WebAppNPS. Webserver. FormL i t era I s.Va I uesC* Dept *3  <>  **  then  begin 
if  srchkeys  «  0  then  begin 
sql.addC >  WHERE  Dept  = 

sql.addC*  *  *  *  +  WebAppNPS-WebServer.FormLiterals.Values[*Dept*]  +  *  * » '); 
incC srchkeys); 
end 
else 

sql.addC  *  and  Dept  =  *  +  **'*  +  CWehAppNPS. Webserver. FormLiterals. ValuesC'Dept*] )+ 

Mil). 

end; 

if  CWebAppNPS. Webserver. FormLiterals.Valuesl'eniptype*]  <>  *ALL*)  and 

not  CWebAppNPS-WebServer.FormLiterals.Values[»emptype*3  =  **>  then  begin 
if  srchkeys  =  0  then  begin 
sql.addC*  WHERE  Status  =  *); 

sql.addC"'*  +  WebAppNPS.  Webserver.  FormL  it  era  Is.  Values  C'emptype*]  +  '***); 
end 
else 

sql.addC  *  and  Status  =*+»'»•+ 

WebAppNPS. Webserver. FormLi terals. Values ['eniptype*]+  *  "  *); 
end; 

sql.addC  *  ORDER  BY  Last,  First'); 

end; 

memol.text  :=  queryl.text; 

end; 

procedure  TWebAppNPS.NPS_ANSWERSectionC Sender:  TObject;  Section:  Integer; 

var  Chunk,  Options:  string); 
begin 


if  section>1  then  exit; 

WebAppNPS.Literal [  *wgrid1.DisplaySet'  3:=  'normal'; 
if  UebAppNPS.Coninand=cCheckboxes  then  begin 
CReset  the  query  when  we  arrive  on  this  page,  coming  from  homepage} 

<Leave  it  alone  if  command  is  something  like  grid. next  > 

Queryl- close ; 

Query1.open; 

end; 

if  ClengthCWebAppNPS. Command)  =  1)  and  CWebAppNPS.CommandCl]  in  C'A'.-'Z'])  then  begin 
WebAppNPS. Webserver. FormLiterals.ValuesC'Last']  :=  WebAppNPS. Command; 

Queryl. close; 

Queryl. open; 
end; 

Cget  the  currect  db  for  the  current  surfer} 

SetSurf erDbC  Surf erTbl ) ; 

end; 

procedure  TWebAppNPS.WebAppNPSEventMacroC Sender:  TWebOutputApp; 

const  aMacro,  aParams,  alD:  string); 
var 

fld:TField; 

IMacro: String; 
s: String; 
begin 

IMacro; = I owercaseC  aMacro) ; 

<  create  the  meaning  of  the  getfield  macro  } 

{.  usage:  getfield| fieldname  --  see  mypages.htm  } 
with  WebAppNPS. WebOutput  do  begin 
if  IMacro  =  'getfield*  then  begin 
with  Surf erTbl  do  begin 

f ld;=findFieldCaParams);  i  aParams  is  info  after  vertical  bar,  i.e.  fieldname  } 
if  fldonil  then  begin 
s:=f Id.asString; 
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Send(s); 

end 

else 

SendCommentC  'Invalid  fieldname:  *  +  aParams  ); 
end; 
end 

else  if  IMacro  =  *getf ieldreg*  then  begin 
with  registerTbl  do  begin 

fld:=findField(aParams);  <  aParams  is  info  after  vertical  bar,  i.e.  fieldname  > 
if  fldonil  then  begin 

if  <f ld.asString=* * )  and  <comparetext(aParams, *  picture *)=0)  then 
SendCnopic.gif  *) 
else  begin 

s:=f Id.asString; 

Send(s); 

end; 

end 

else 

SendCommentC  'Invalid  fieldname:  *  +  aParams  ); 
end; 
end 

else  if  IMacro  =  'getf ieldmain*  then  begin 
with  main  do  begin 

f ld:=findField(aParams);  {  aParams  is  info  after  vertical  bar,  i-e.  fieldname  > 
if  fldonil  then  begin 
s:=f Id-asString; 

Send(s); 

end 

else 

SendCommentC  'Invalid  fieldname:  »  +  aParams  ); 
end; 
end 

else  begin 

SendCommentC  'Invalid  custom  macro  event:  '  +  aMacro  ); 
end; 
end; 

end; 


procedure  TUebAppNPS.NPS_DETAILSectionCSender:  TObject;  Section:  Integer; 

var  Chunk,  Options:  string); 
var 

s, user, picfilenaine:string  [128] ; 
begin 

if  section  >  1  then  exit; 

Cour  job  here  is  just  to  locate  to  the  correct  record  > 

s  :=  webcommandlinel .mcommand; 

SetSurferDbCSurferTbl ); 

SurferTbl . locateC ' Id* ,s, C3 ); 

Cthe  surfer  table  should  include  the  registertbl  Ci.e.,  the  query  should  execute 
but  this  is  a  quick  an  outer  join  on  main.db  with  registertbl -db.  then  we  can 
get  rid  of  the  getfieldreg  macro  Cl  think?) 
if  notCRegistertbl. locateC 'FkID',s,[]))  then 

Registertbl. locateC'FkID', 'blank*, []);  //  this  is  a  tenp  fix  for  those 

//  who  are  not  registered 
//  it  points  to  a  blank  record 
//  in  the  register  tbl 

end; 

procedure  TWehAppNPS.SetSurferDbCTbl :TTable); 
begin 

if  Tbl.tablename  =  WebAppNPS.Literal ['DBName']  then  exit; 

Tbl. close; 

Tbl.tablename  :=  WebAppNPS.Literal ['DBName'] ; 

Tbl. open; 

SetDBEnvCTbl); 

end; 
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procedure  TWebAppNPS . SetDBEnvCTbl : TT able) ; 


begin 

with  Tbl  do  begin 

fieldByName( 'Last* ).displayLabel ;=* LAST  NAME*; 
fieldByName( 'First* ).displayLabel :=*FIRST  NAME*; 

f  i  eldByName(  *  Etna  i  I  * )  -  di  splayLabe  I ; = *  <  I  MG  SRC=%=:  i  mageD  i  r=%ma  i  I  to .  g  i  f  >  EMA I L  * ; 
f i  eldByNameC  *  Phone  * ) -di splayLabel : = *  < I MG  SRC=%=imageD i r=%phone1 - gi f >PHONE  * ; 
fieldByNameC 'Middle* ).displayLabel :=*MI *; 
fi eldByNameC *URL * ) -di splayLabel HOMEPAGE  (URL) * ; 

{set  hot  field} 

f i eldByNameC 'Last *) -tag: =HotFieldTag; 
fieldByNameC'Email* )-tag:=HotFieldTag; 
f ieldByName(*URL*).tag:=HotFieldTag; 
end; 
end; 

procedure  TWebAppNPS. NPS_ANSWERREGSection( Sender:  TObject; 

Section:  Integer;  var  Chunk,  Options:  string); 
begin 

if  section>1  then  exit; 

WehAppNPS.Literal C  *wgrid2.DisplaySet *  3:=  'normal*; 
if  UebAppNPS . Con)mand=cCheckboxes  then  begin 
{Reset  the  query  when  we  arrive  on  this  page,  coming  from  homepage} 

{Leave  it  alone  if  command  is  something  like  grid. next  } 

Queryl. close; 

Queryl .open; 
end; 

{get  the  correct  db  for  the  current  surfer} 

SetSurferDbCSurferTbl); 

end; 

procedure  TWebAppNPS. NPS_DETAILREGSection( Sender:  TObject; 

Section:  Integer;  var  Chunk,  Options:  string); 
var 

s:string[128] ; 
begin 

if  section>1  then  exit; 

//  I  need  this  here  so  that  the  conditional  will  work  properly 
WehAppNPS.Literal [  *Fai IRegister*  ]:=  *'; 

{our  job  here  is  just  to  locate  to  the  correct  record  } 

^y**************************************** 

//*  VERY  IMPORTANT!!  THIS  LATER  NEEDS  TO  BE  THE  MAIN  DATABASE  ON  THE  DEC... NOT 
//*  THE  TEMP  QRY*.DB  TABLES!  Ill  SAME  GOES  FOR  THE  OTHER  DETAIL  **ONSECTION" 

//*  PROCEDURE!  II!  MM! 

yy***************************************** 

s  :=  webcommandlinel.mcommand;  //  we  are  using  webCommandLinel  instead  of  Webapp. command 
WehAppNPS.Literal ['MainID*]  :=  s;  //  because  the  webapp. command  translates  to  uppercase 
SetSurferDbCSurferTbl ) ; 
with  SurferTbl  do  begin 
locateC*Id*,s,E3); 
end; 
end; 

procedure  TWebAppNPS. NPS_FBREG I STERExecuteC Sender:  TObject; 

var  Continue:  Boolean); 
var 

sur f erEMa i I , password : s  t  r i ng ; 
begin 

sur f erEMa i I : ^WebAppNPS - L i tera I E ' ema i I reg  * ] ; 
if  surferEMai l="  then  begin 
with  WebA^PS  do  begin 

SendStringC  *You  have  to  enter  your  email  addressl<p>*  ); 
continue;=False; 
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end; 

end 

else 

with  registertbl  do  begin 
open; 

WebAppNPS. Liters  I [  *Fai IRegister*  ] :=  »»; 
if  findkey([surferEmail3)  then  begin 

UebAppNPS. Liters  I [  *Fsi [Register'  ] :=  *T*; 

BounceToC 'Detai I Reg Fa i I  * ); 
end 

else  begin 

password  :=  generatePassword; 

//****  Should  use  the  dynamic  creation  of  a  query  and  then  use  SQL  Insert  because 
//  another  surfer  could  change  the  record  pointer. .. leaving  you  with  update 
//****  anomalies  ...  this  really  shouldn't  be  a  problem  if  we  are  appending.. 

//  right??? 

append; 

fieldbynameC 'Password' ).asString  :=  password; 
fieldbyname(*ID').asString  :=  trim(surferEmail); 
fieldbyname('FkID').asString  :=  WebAppNPS.LiteralC'MainID']; 
fieldbynameC 'activated'). value  :=  false; 
post; 

//  What  if  mail  fails???  should  I  use  expiration  date... or  some  kind  of 
//  exception  on  email  failure???? 
with  webmaiU  do  begin 
Hai Ito. clear; 

Mai lto.add(surferEmai I ); 

Lines. clear; 

Lines.addC 'Once  you  login  your  account  will  be  activated'); 

Lines.add( 'Your  Login  is:  '  +  surferEmail); 

Lines.addC 'Your  password  is:  '  +  password); 
subject  :=  'Registration  Information'; 
execute; 
end; 
end; 
end; 


end; 


//  This  is  not  a  sophisticated  password  genera  tor...  it  is  used  only  to  demonstrate 
//  the  concept  within  this  ai^li cat ion's  environment  and  it  serves  the  purpose, 
function  TWebAppNPS.GeneratePassword  : string; 
var 

I:  Integer; 

Pass:  string; 
begin 

Randomi ze; 

Pass:=  ' '; 

for  I  :=  1  to  6  do  begin 
Pass  :=  Pass  +  chr(Random<26)+65); 
end; 

generatePassword  :=  Pass; 
end; 

procedure  TWebAppNPS.NPS_DETAILLOGSection(Sender:  TObJect;  Section:  Integer- 
var  Chunk,  Options:  string); 
var  s:string; 
begin 

if  section  >  1  then  exit; 

//  protebly  should  use  a  unique  query  here... another  surfer  could  change  the 
//  position  of  the  record  pointer.  You  should  create  a  query  on  the  fly???  and 
//  either  assing  values  to  literals  and  "free"  the  query...  or  ..."free"  the  Query 
//  using  the  "onexecdone"  event?!  (Remember. . .you  will  also  have  to  change  the 
//  getfields  macros... eeee  can  we  do  this???)  Maybe  we  don't  have  to  use  getfields 
//we  can  Just  use  the  literals. ..then  use  a  query  to  update.... 

s  :=  registertbl.fieldbyname('FkID').asstring; 
inain.locate(*ID',s,  [)); 
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end; 

procedure  TWehAppNPS.NPS_DETAILLOGExecute( Sender:  TObject; 

var  Continue:  Boolean); 
var  s:string; 
begin 

memol.text  :=  Uok=  *  +  WebAppNPS.Literal [*LoginOk']  +  *  loginPend=  *  + 

WehAppNPS.Literal  [*LoginPending*]  +  •  getlit(login)=  »  +  getliteraU  Uogin*  ); 

if  note  UebAppNPS.Literal ['LoginOk']  =  'TRUE*)  and 

not(WebAppNPS-Literal  C'LoginPending']  =  'TRUE')  then  begin 
BounceToC 'LoginPg' ); 
exit; 
end; 

if  notCWebAppNPS.Literal ['LoginPending'3  =  'TRUE')  then 
exit; 

<We  only  want  to  do  this  if  the  user  is  trying  to  login> 
s:=  getLiteraU 'Login'); 

if  not(registerTbUlocate('ID',s,  [locaseinsensitive] ))  then  begin 
BounceT  o( ' Logi nFa i I ' ) ; 
end 

else  if  regi  sterTbl.fieldbynameC  password ').  asst  ring  <>  WehAppNPS.Literal  ['password']  then  begin 
BounceToC 'LoginFai I ' ); 
end 
else 

WehAppNPS.Literal ['Logi nOk']  :=  'TRUE'; 

WehAppNPS.Literal ['Logi nPending' 3  :=  'FALSE'; 
end; 


procedure  TWebAppNPS.NPS^FBUPDATEExecuteCSender:  TObject; 

var  Continue:  Boolean); 
var  updateQry:TQuery; 
begin 

if  WehAppNPS.Literal C'LoginOk'3  <>  'TRUE'  then  begin 
BounceToC 'Login'); 
exit; 
end; 

updateQry  :=  Tquery.CreateCSelf ); 
with  updateQry  do  begin 

databasename  :=  'locator';  //  make  this  a  constant  so  we  only  have 

//  to  change  once. 

//updatemode  :=  [wherekeyonly]; 
sql.addC 'update  REGISTER  >); 

sql.addC'set  URL2  =  '"  +  getFormLiteralC'url2' )  +  "','); 
sql.addC  PH0NE2  =  '"  +  getFormLiteralC 'phone2')  +  ); 

sql.addC  FAX2  =  '"  +  getFormLiteralCfax2' )  +  ); 

sql.addC  COMMENTS  =  *>»  +  getFormLiteralC 'comments')  +  ); 

sql.addC  ACTIVATED  =  "1"  '  ); 
sql.addC  where  ID  =  " '  +  getLiteralC  login' )  +  ""); 

memol.text  :=  sql.text; 
execsql; 
close; 
sql. clear; 

sql.addC  update  MAIN  m  set  m.  regi  stored  =  "1"  '); 
sql.addC  where  m.id  =  Cselect  FkID  from  REGISTER  '); 
sql.addC  where  ID  =  "*  +  getLiteralC  login* )  +  *")*); 

memol.text  ;=  sql.text; 
execsql; 
free; 

end; 

end; 

procedure  TWehAppN PS. NPS_HOMEPAGEExecuteC Sender:  TObJect; 

var  Continue:  Boolean); 
begin 
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if  (UebAppNPS. Command  =  'LOGCXJT')  then  begin 
WebAppNPS. Literal ['LoginOk']  :=  'FALSE'; 

WebAppNPS. Literal ['LoginPending']  ;=  'FALSE'; 
editl.text  :=  editl.text  +  'logout'; 
end; 
end; 

procedure  TWebAppNPS.NPS^LOG I NPGExecDoneC Sender:  TObject); 
begin 

WebAppNPS. Literal ['LoginPending *3  ;=  'TRUE*; 
end; 

procedure  TWebAppNPS-NPS^HOMEPAGE Sect ion (Sender:  TObject;  Section:  Integer; 

var  Chunk,  Options:  string); 
begin 

if  section  >  1  then 
exit; 

if  (WebAppNPS. Command  =  'LOGOUT')  then  begin 
WebAppNPS. Literal ['LoginOk']  :=  'FALSE'; 

WebAppNPS.Litera I ['LoginPending']  :=  'FALSE*; 
editl.text  :=  editl.text  +  'logout'; 
end; 
end; 

futility  Functions} 

function  TWebAppNPS.GetLitera I (Literal Name  :string):string; 

fRead  a  literal  y 

begin 

result  :=  WebAppNPS. Literal [Li tera I Name]; 

end; 

. . . 

function  TWebAppNPS.GetFormLiteral(LiteralName:string):  string; 

fread  a  form  literal} 

begin 

result  :=  WebAppNPS.WebServer-FormLiterals.Values[LiteralName] ; 

end; 

Procedure  TWebAppNPS.PutLi tera ULiteralName, Li tera IValueistring); 

<Add  or  update  a  WebApp  literal} 
begin 

WebAppNPS. Li tera I [Li tera I Name]  :=  Li tera I Value; 
end; 

procedure  TWebAppNPS . BounceTo( Pagel D ; st  r i ng ) ; 
begin 

webappoutput. sendbounceto(webappnps. eg i caller  +  *?nps:*  +  PagelD  +  *:*  + 

1 nt tost r ( webappnps . sess 1  on) ) ; 

end; 


^★********************************  TESTING  AREA  FOR  UPLOAD  ****************> 


procedure  TWebAppNPS. UpLoadUserFi les; 

f looks  for  the  source  and  companion  files  for  this  job  } 

var 

uplinfo,  ThisEntry  :  string; 

NewFileName,  ClientFi leName:  string; 

JobFileType  :  string; 

begin  {save  uploaded  files} 

fWe  don't  want  to  do  anything  if  we  didn't  get  here  from  the  send  page} 
floop  over  the  list  of  files  to  upload 
with  Webserver. webini  do  begin 
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ThisEntry  :=  ‘uploadf i le*; 
section  :=  'Form  File*; 
entry  :=  ThisEntry; 
upLinfo  :=  StringVaLue; 
end; 

memol.text  :=  uplinfo; 

//  Should  use  a  constant  (or  ini  file)  for  Webserver  path!! 

NewFileName  :=  clmageDir  +  get  I iterate 'Login* ); 

if  uplinfo  <>  "  then  begin 

SaveUploadFi  le(upllnfo,NewFi  leName,ClientFi  leName); 
end 

else  begin 

WebAppNPS.  UebOut  put .  Send 

(  *<center>  <font  size=5><b>  No  File  has  been'  + 

*  uploaded  --  you  must  enter  a  valid  gif  or  jpeg  picture  file* 

+  *</b></font></center><br>*  ) 

end; 

end; 

procedure  TUebAppNPS. SaveUploadFi I e( const  Uploadinforstring; 

var  NewF i I eName , C I i ent  F i I eName : S t r i  ng) ; 
const  MAXLEN=255; 
var 

Name,  EMail,  Desc  :  string; 

UploadFileName,  ServerFi leName:  string; 

F i I eS i ze, F i I esType, F i I esTypeTes t : st  r i ng; 
ws,wsl,wsr  :  string; 

Ent ry , St r i ngVa I ue : St r i ng; 

FileToDelete  : array [0. .255]  of  char; 

UploadFile:  file; 

PicOK: boo lean; 
srstring; 

begin 

<This  code  relies  heavily  upon  some  very  handy  string 
processing  a  parsing  routines  in  the  ucstring.pas  unit 
of  the  complete  TPack  code  > 

<The  following  comment  contains  a  sample  value  for  UploadInfo:> 

C 

EC:\WebSite\cgi-temp\66ws.001]  46  text/plain  binary  CC:\PROJECT\README-TXT] 

> 

memol.text  :=  memol.text  +  *  *  +UploadInfo; 
ws  :=  Uploadlnfo; 

SplitStringCws, '] *,wsl,ws); 

ServerFi leName  :=RightOf(*  E',wsl); 
memol.text  :=  memol.text  +  '  *  +  serverFi lename; 

SplitString(ws, ' C*,wsl,wsr); 

ClientFileName  :=  LeftOf( *] * ,wsr); 

wsl:=  TrimLeft(wsl); 

SplitStringCwsl, •  * ,Fi leSize,Fi lesType); 

Fi lesTypeTest  :=  trim(LeftOf( *  ' ,Fi lesType)); 

PicOK  :=  False; 

if  (Fi lesTypeTest  =  ' image/gif ' )  then  begin 
newfi lename  :=  newfi lename  +  '.gif';  ' 

PicOK  :=  TRUE; 
end 

else  if  (Fi lesTypeTest  =  'image/jpeg')  then  begin 
newfi  lename  :=  newfi  lename  +  '.jpg'; 

.  PicOK  :=  TRUE; 
end; 

if  PicOK  then  begin 

ForceFi  leRename(serverFi  lename,NewFi  leName);  //should  have  error  checking  here 
WebAppNPS.  WebOut  put .  Send 

(  *<center>  <font  size=5><b>  File='  +  ClientFileName  +  '<br>  has  been  •+ 
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•successfuly  uploaded  and  saved  as  •  +  ExtractFi lenanne(newf i lename) 
+  *</b></font></center><br>*  ); 
s:=  getliteralCLogin*); 
with  registertbl  do  begin 
locate('ID*,s,[]); 
edit; 

Fieldbyname( 'picture* ).asstring:=  ExtractFilename<newfi lename); 
post; 


end 

else 

WebAppNPS - WebOut put  - Send 

(  *<center>  <font  size=5><b>  File=*  +  ClientFi leName  +  »<br>  has  not  been  uploaded  because 
*it  was  not  a  gif  or  jpg  </b></f ont></center><br> •  ); 


end; 


procedure  TWebAppNPS. NPS_FBUPLOADP I CExecute( Sender:  TObJect; 

var  Continue:  Boo lean) ; 
begin 

if  WebAppNPS  -  Li  teraU*  Log  inOk*]  <>  'TRUE*  then  begin 
Bounce! o( *  Log i n  * )  ; 
exit; 
end; 

uploaduserfi les; 
end; 

procedure  TWebAppNPS-NPS_UPLOADPICExecute(Sender:  TObject; 

var  Continue:  Boolean); 
begin 

if  WebAppNPS-LiteralC'LoginOk']  <>  'TRUE*  then  begin 
BounceToC  *  Login' ); 
exit; 
end; 
end; 

procedure  TWebAppNPS.NPS_LOGUPDATESection< Sender:  TObject ; 

Section:  Integer;  var  Chunk,  Options:  string); 
var  s:stringCl28] ; 
begin 

if  section  >  1  then  exit; 

//  probably  should  use  a  unique  query  here. ■ -another  surfer  could  change  the 
//  position  of  the  record  pointer.  You  should  create  a  query  on  the  fly???  and 
//  either  passing  values  to  literals  and  "free"  the  query...  or  ..."free"  the  Query 
//  using  the  "onexecdone"  event?l  (Remember. . .you  will  also  have  to  change  the 
//  getfields  macros. -.eeee  can  we  do  this???)  Maybe  we  don't  have  to  use  getfields 
//  we  can  just  use  the  literals... then  use  a  query  to  update.... 
s:=  getLiteraK 'Login'); 
registertbl . locateC » ID ' ,s, [] ); 
s  :=  registertbl.fieldbyname(*FkID*)-asstring; 
main.locate<'ID»,s, []); 


end; 


procedure  TWebAppNPS.NPS^LOGUPDATEExecute( Sender:  TObject; 

var  Continue:  Boolean); 
begin 

if  WebAppNPS. Literal E'LoginOk']  <>  'TRUE*  then  begin 
BounceToC 'Login'); 
exit; 
end; 
end; 


procedure  TWebAppNPS.ForceFileRename(const  oldName,newName:string); 
begin 

if  DeleteFile(pchar(newName))then  //I  shouldn't  have  to  type  cast  as  PCharM ! 
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editl.text  :=  'delete*; 
if  RenameFi leColdName^newName)  then 
editl.text  :=  editl.text  +  'rename*; 


end; 

procedure  TWebAppNPS.NPS_FBUPLOADP I CSectionC Sender:  TObject; 

Section:  Integer;  var  Chunk,  Options:  string); 
van  s:string; 
begin 

if  section  >  1  then  exit; 
s:=getliteral( *  login* ); 
registertbl . locateC  *  id* ,s, C3 ); 
end; 

procedure  TWebAppNPS.NPS_CHGPASSExecute( Sender:  TObject; 

var  Continue:  Boolean) ; 
begin 

if  WebAppNPS.Literal ['LoginOk']  <>  'TRUE*  then  begin 
BounceT  o( *  Logi n  * ) ; 
exit; 
end; 
end; 

procedure  TWebAppNPS.NPS_FBCHGPASSExecute( Sender:  TObject; 
var  Continue:  Boolean); 
var  s:string; 
begin 

if  WebAppNPS.Literal ['LoginOk'3  <>  'TRUE*  then  begin 
BounceTo( *  Login* ); 
exit; 
end; 

if  getFormLiteraU 'chpassi  * )  <>  getFormLiteraU *chpass2* )  then 
BounceToC 'ChgPassFai I ' ) 
else  begin 

s:=  getLiteraU 'Login* ); 

editl.text  :=  s  +  *  *  +  getFormLiteraU 'chpassi  *  ); 
with  registertbl  do  begin 
locate(*Id*,s,E]); 
edit; 

fieldByNameC 'password* ).asSt ring  :=  getFormLiteraU 'chpassi ' ); 
post; 
end; 
end; 
end; 


end. 
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